Platform for data aggregation, communication, rule evaluation, and combinations thereof, using templated auto-generation

ABSTRACT

Platforms for data aggregation, communication, rule evaluation, and combinations thereof are described. The platform may include three distinct functional layers; a core layer, an adaptive layer and an intelligence layer. Furthermore, the platform may include a data block, messaging block, rule block, or combinations thereof. Generally, the platform may facilitate data acquisition, storage, and manipulation between and among clients and data sources in a generic manner. That is, clients may communicate and make requests independent of a target system or database type. The platform may process the communications and requests in a manner suitable to the target system or database type. The platform may also evaluate rules received from the clients in a manner generic to the client application. Instances of the platform for a given application may be efficiently created using a template-based mechanism, for example for supporting a variety of end user applications in a flexible, scalable manner.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a divisional of pending U.S. patent application Ser.No. 12/392,900, filed Feb. 25, 2009, which application claims thebenefit of U.S. Provisional Application Ser. No. 61/067,162, filed Feb.25, 2008. These applications are incorporated by referenced herein, intheir entirety, for any purpose.

TECHNICAL FIELD

Embodiments of the invention relate to methods and systems for robustdata handling, in particular generic formulations for dynamicallycommunicating, manipulating, storing, or taking a combination of thoseactions with a variety of data sources and client types.

BACKGROUND

Widespread use and acceptance of computer systems has resulted in aproliferation of data. A wide variety of enterprises and individualsgenerate and store large amounts of data. Data mining and analysis hastherefore become increasingly important as people and enterprises try toglean intelligence from their data.

However, data mining and analysis efforts have been hampered by thelarge and disparate formats in which data may be stored and manipulated.Custom software is typically required to build system-wide solutionsthat combine data in a particular way, or implement a specific analysistechnique.

For example, a retail store seeking to store, mine and analyze theirdata in a meaningful way faces a variety of challenges. The store maywant to collect data from a variety of locations. One source of data isthe store itself—inventory on hand, and daily sales, for example.Another source of data are the store's suppliers. The suppliers all mayhave their own data about inventory availability, price, and selection.The store's customers may also have their own data about their purchasehistory at that and other stores and demographic data, for example.

Store personnel generally are required to make a variety ofdecisions—such as which items to order, and how much of each item toorder and at what time. Knowledge and the ability to analyze data fromall of the above-mentioned sources may be able to aid in this decision,but only if the data is readily available and can be analyzed inaccordance with criteria that will be useful to the store personnel.

Creating a software solution that is able to aid the store personnel ina meaningful way may require the ability to interface with the disparatesystems that hold the store data, supplier data or data of otherexternal entities, and customer data. Moreover, the software solutionmust be able to manipulate this information in accordance with theanalytical criteria the store personnel would like evaluated.

Of course, many existing software systems aimed to mitigatecommunication between specific disparate data types or conduct aspecific type of analysis on a given set of data. However, softwaredevelopers routinely focus only on the problem at hand and build aspecific software solution to connect the store's database with thedatabase of the supplier, for example. The software itself is likely todepend on the particular data attributes used by the store and thesupplier. Similarly, a software developer is likely to build ananalytics solution that specifically answers the question posed by thestore personnel. The analytics solution may be hardcoded to process thespecific attribute types contained in the supplier and store databases,and compute one or a series of specific calculations desired by storepersonnel.

Accordingly, when the store or the supplier or a customer changes oradds a database type, a data attribute, or when store personnel wouldlike data analyzed in a new manner, the software developer is requiredto intervene and change the software code used to analyze the data. Thisprocess may be cumbersome and it may limit the store's ability to haverich interactions with its data and change the analytical techniquesused or the type of data analyzed.

Furthermore, due to the specific nature of the software involved, thestore's solution will be unsuitable for another entity trying to performa completely different data analysis task. For example, the store'sinventory software solution would be completely unsuitable for analyzingtraffic patterns on a nearby interstate. To handle traffic patternanalysis, the software developer would need to develop a new softwaresolution from the ground up.

A brief summary of challenges in three areas are described below: 1)storing and sharing data amongst different database types; 2)communicating between different and unknown system types; and 3) actingon stored information.

Storing and Sharing Data

A brief overview of database storage and interoperability challengeswill be described with reference to FIG. 1. Electronic databases, suchas database 10 in FIG. 1, store data and are configured to access andmanipulate the stored data according to various objects specified by thedatabase, such as ObjectA in FIG. 1. An object is generally a collectionof data and methods for manipulating the data. The objects may specify avariety of methods for manipulating the data, including methods forcreating, reading, updating or deleting data entries in the database.MethodA and MethodB are shown in FIG. 1 associated with ObjectA.

An application programming interface (API) 15 provides access to themethods in the database 10. The API 15, for example, supports MethodAand MethodB used in the database 10. Clients access the database 10 bycommunicating a message 20 to the API 15. The message includes one ofthe functions supported by the API. So, for example, in FIG. 1, Client25 passes a message 20 that includes a request to execute ‘MethodA’ andparameters for the execution of MethodA. Recall that MethodA is aspecific method supported by the database 10.

Accordingly, the API 15 may achieve relatively high performance, becauselittle if any manipulation must be performed on the received message 20before passing a function call 30 to the database 10 to perform MethodAwith the enclosed parameters. However, the API 15 is not very flexible.

For example, if database 10 stores customer information, ObjectA mayrefer to a customer, and MethodA may include a method entitled‘GetCustomer’ which operates to retrieve a customer number based on anorder number and a purchase date. Code used to implement the API 15 maythen include the statement:

int GetCustomer (int OrderNumber, Date Time, PurchaseDate);

‘int’ indicates the API is expecting an integer (the customer number)returned from this call. The API also expects an integer order numberand a date/time formatted purchase date to be transmitted along with therequest. Message 20 must then include “GetCustomer (OrderNumber,PurchaseDate)”.

The API then passes the message 20 as a function call 30 to the database10.

Databases have various internal mechanisms for communication andformatting for function calls and parameters including any of a varietyof querying languages specific to the database type such as SQL, arelational database query language or the like. The API 15 is specificto the database 10 and formats the message 20 into a proper functioncall 30 for the database 10.

There are several drawbacks to this approach for database communicationthat become increasingly apparent as databases become increasinglycomplex and numerous.

A first drawback is that the API 15 supports only the specific methodssupported by the database 10. Once the source code for the API 15 iscompiled, it becomes a static entity and cannot support any furthermethods. If the database 10 is changed to a different database thatsupports, say, MethodC instead of MethodA, the API 15 will not be ableto generate a function call for MethodC. The API 15 will need to berewritten and recompiled to support the new method. This requires thatthe API 15 be taken off-line (stopped or taken out of service) while anew API is written, compiled, and put back into service.

Another drawback is that the API 15 supports only the specificcommunication language used by the database 10. The API 15 only formatsmessages for a particular database language. Again, if the database 10is changed to a different database utilizing some other internallanguage, the API 15 must be rewritten and recompiled, requiring timeand a suitably skilled operator to perform the update.

The above drawbacks to database communication apply generally to allavailable database types including relational databases andobject-oriented databases. Older database models, such as hierarchicaland network models, also have the described drawbacks.

Communicating Between Different or Unknown System Types

As data collection and mining become increasingly important andsophisticated, communicating among complex systems for storing andmanipulating data has become difficult. Separate applications or systemshave their own internal methods of communicating and syntax andvocabulary for storing and manipulating data. A same or similarprocedure may have different names in different databases or systems,for example. One application may want to call that procedure in avariety of different databases.

Present systems handle this communication difficulty by calling thespecific procedure name for each system of interest. For example, a codefragment from a first system may call an IOrderFulfillment interface aspart of the implementation of a call implementing an interface foraccepting orders. An interface is generally a portion of code thatreceives calls from clients and mediates access to an underlyingprocedure or data store. The Accept Order class may be coded as follows:

public void AcceptOrder (string Order) {     IOrderFulfillment iof = newOrderFulfillmnet( );     iof.FulfillOrder(Order);   }

This class needs to communicate with the IOrderfulfillment interface,implemented by a second system. The Fulfillment interface may itselfneed to communicate with a further interface, such as a shipmentinterface. The second system may encode an order fulfillment interfaceas follows:

public interface IOrderFulfillment {   void FulfillOrder (string Order);} public class OrderFulfillment : IOrderFulfillment {   public voidFulfillOrder(string Order)   {   IOrderShipment iof = new OrderShipment();   iof.ShipOrder(Order);   iof = new OrderShipmentEx( );  iof.ShipOrder(Order);   } }

The above examples contains two separate calls to an order shipmentinterface—one to OrderShipment( ) and one to OrderShipmentEx( ). Thesetwo consecutive calls are necessary to communicate with a third andfourth system, each of which implement the order shipment interface. Oneimplementation, the third system, codes the order shipment interface as:

-   -   public class OrderShipment:IOrderShipment

Another implementation, the fourth system, implements the order shipmentinterface as:

-   -   public class OrderShipmentEx: IOrderShipment

The second system above was accordingly required to make two consecutivecalls, one to the order shipment interface as specifically implementedby the third system and the other to the order shipment interface asspecifically implemented by the fourth system. A problem may arise ifthe third or fourth system, or both, are changed to different or newsystems that no longer support the particular format of the calls madeby the second system. If the implementation of the shipment interfacechanges, the implementation of the fulfillment interface of system twomust be correspondingly changed and recompiled, which may beundesirable.

Acting on Stored Information

A variety of actions may be desirable using collected, stored data. Inparticular, an organization or entity may desire to evaluate a varietyof conditions on stored data. However, the conditions will varyaccording to the type of data and the purposes of the requestor. Forexample, a thermostat application may desire to set a temperature to awarm setting if stored data indicates it is cold outside and it is themorning. This is a simple example of a type of rule that an applicationmay desire to evaluate. The permutations of rules may vary widelyaccording to the end use of an application, and the types of dataavailable.

The common approach to the execution of rules would be to hard code therule into the software system. So for example, a thermostat applicationmay contain lines of code that are specific to the condition and actiondescribed above, that is, to temperature and temperature settings. Thecode would explicitly recite parameters such as ‘temperature’ and ‘set’.Should the users of a temperature application want to implement adifferent rule—for example, if an occupant is detected in a room, setthe temperature to a certain level, or if it is night then settemperature to cold—a new code would be required to implement andevaluate the rule. This may require taking the system offline, preparingcode, recompiling the code, and restarting the system.

The above description identifies some of the challenges in supplying arobust, scalable, rule-based expert system. While software may beprepared to interface specific disparate data systems and evaluate rulesfor a particular given end use, the resultant software application maybe no more flexible than before. That is, the software is still confinedto the particular use for which it was designed, and the specificsystems for which it was designed to integrate. The addition orsubtraction of systems, or the revision, addition, or subtraction ofrules to be evaluated may require stopping the system, commissioning thepreparation of specific new software code, re-compiling the software,and redeploying the software solution. This procedure may be cumbersomeand limit the usefulness of any one particular software solution.Ultimately the time involved in a system shutdown, code drafting,re-compiling, and re-deployment, along with additional time for testing,may be prohibitive in designing or deploying a system change.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of database communication according to theprior art.

FIG. 2 illustrates a schematic diagram of components of a data handlingplatform 100 according to an embodiment of the present invention.

FIG. 3 is a schematic diagram of a platform according to an embodimentof the present invention.

FIG. 4 is a schematic diagram of a system including a data blockaccording to an embodiment of the present invention.

FIG. 5 is a schematic diagram of a system implementing a method fordatabase communication according to an embodiment of the presentinvention.

FIG. 6 is a schematic diagram of a payload according to an embodiment ofthe present invention.

FIG. 7 is a schematic flowchart of a method for processing a payloadaccording to an embodiment of the present invention.

FIG. 8 is a schematic flowchart of a method for formatting a call for aspecific database type according to an embodiment of the presentinvention.

FIG. 9 is a schematic diagram of a method for creating templatesaccording to an embodiment of the present invention.

FIG. 10 is a schematic diagram of a template according to an embodimentof the present invention.

FIG. 11 is a schematic diagram of a method for auto-generating an objectin a target database according to an embodiment of the presentinvention.

FIG. 12 is a schematic diagram of a payload according to an embodimentof the present invention.

FIG. 13 is a schematic diagram of a system according to an embodiment ofthe present invention.

FIG. 14 is a schematic diagram of a messaging block according to anembodiment of the present invention.

FIG. 15 is a schematic diagram of a message according to an embodimentof the present invention.

FIG. 16 is a schematic diagram of a system including a messaging blockaccording to an embodiment of the present invention.

FIG. 17 is a flowchart for a method of administering and using amessaging block according to an embodiment of the present invention.

FIG. 18 is a schematic diagram of a system including a rule blockaccording to an embodiment of the present invention.

FIG. 19 is a schematic diagram of a text to pledge system using aplatform according to an embodiment of the present invention.

FIG. 20 is a schematic diagram of a point of sale system using aplatform according to an embodiment of the present invention.

DETAILED DESCRIPTION

Certain details are set forth below to provide a sufficientunderstanding of embodiments of the invention. However, it will be clearto one skilled in the art that embodiments of the invention may bepracticed without various of these particular details. In someinstances, well-known computer systems and architecture, softwareoperations and protocols have not been shown in detail in order to avoidunnecessarily obscuring the described embodiments of the invention.Embodiments of the present invention may be implemented in all or inpart as executable instructions encoded in a computer-readable mediumthat, when executed, cause one or more processors to perform thefunctionalities described. In some embodiments, hardware or firmware maybe used in all or in part to perform the functionalities.

Section headings may be used in this document. The section headings areintended only as an explanatory guide to the document. The sectionheadings are not meant to imply that all information related to theheading is found in that section, or that no information related to thatheading may be found in other sections. To the contrary, embodiments ofthe present invention provide integrated systems whose individualcomponents may be highly interrelated. Accordingly, information aboutany one component may impact the functionality and workings of othercomponents. Accordingly, individual components should be interpreted inlight of the entire description herein, and their description is notisolated to any one section.

FIG. 2 illustrates a schematic diagram of components of a data handlingplatform 100 according to an embodiment of the present invention. FIG. 2is intended to depict a variety of possible components of the platform,it is to be understood that all components will not be present in allembodiments. Embodiments of a data handling platform 100 mayconceptually be viewed as having a variety of layers—an intelligencelayer 60, adaptive layer 55, and core layer 50, for example. The layers50, 55, and 60 are conceptual and are intended to illustrate levels ofabstraction in data handling to facilitate communication between andamong one or more clients and one or more data sources, as will bedescribed further below. The layers 50, 55, and 60 are not intendedsolely to indicate physical divisions between computing devicesconfigured to perform the described functionalities, although in someembodiments the layers may be physically divided, while in others asingle computing device may be configured to perform all the describedfunctionalities.

Generally, then, the layers 50, 55, 60 represent a conceptual distancefrom a data source in that the components depicted in the core layer 50are process data that is closer to raw data stored in one or more datasources (not shown). These components—such as data, messaging, securityand management, in some embodiments manipulate raw data to abstract,communicate, apply security or manage the data. The adaptive layer 55may provide some context to the data, providing and manipulatinginformation concerning, for example, preferences, context, and rules andinteraction. The intelligence layer 60 may further add information toenrich the context of the data or transactions involving data. Forexample, the intelligence layer 60 may generate knowledge based on thedata manipulated by the core layer 50 and context-enriched by theadaptive layer 55. The intelligence layer 60 may uncover or recognizepatterns or relationships in the data, or infer additional informationabout the data based in some examples on both the data and the contextor preferences provided by the adaptive layer 55. Any of a variety ofintelligence modules may be used to impart a variety of different typesof intelligence to the data gathered and processed by the core layer 50and context-enriched by the adaptive layer 55. Finally, any of a varietyof applications 65 may be written and implemented on any suitablecomputing device to put the functionality provided by the platform 100to one or more specific end uses. Donation functionality and point ofservice applications, for example, will be described further below.Other applications may be implemented in other embodiments.

FIG. 3 is a schematic illustration of a platform 100 according to anembodiment of the present invention. The platform 100 generallyfacilitates interaction between one or more data sources 150, and one ormore clients 140. Although shown as unassociated in FIG. 3, some of thedata sources 140 may be associated with one or more of the clients 150.That is one or more of the clients 150 may host one or more of the datasources 140 and the hosted data source available to the platform 100through the hosting client. The data sources 150 may generally be of anytype, including, but not limited to, databases such as Oracle, SQLserver, XML, binary files, and various in-memory structures. The datasources 150 may be connected to the platform 100 through any availablecommunication means, and may not be physically co-located with theplatform 100. Similarly, the clients 140 may not be physicallyco-located with the platform 100 and may be in communication with theplatform 100 through any available communication mechanism. A variety ofclients 140 may be in communication with the platform 100 including, butnot limited to, computers, cell phones, personal digital assistants,kiosks, or set top boxes, navigation devices or televisions.

As will be described further below, the platform 100 generallyrepresents an architecture that can implement a rule-based expertsystem. The platform 100 communicates, stores, and manipulates data in ageneric way such that any number of clients and data sources may beadded, deleted, or changed. The platform 100 may be implemented by oneor more computing devices with sufficient memory and software toimplement the functionalities described. The platform 100 includes threecomponents: a data block 110, a messaging block 120, and a rule block130. Although all three components are shown in the platform 100, insome embodiments one or more of the blocks may not be implemented. Eachof the ‘blocks’ 110, 120, and 130 generally include one or moreprocessors and associated memory storing encoded software sufficient toperform the described functionalities. One or more of the blocks 110,120 and 130 may utilize a same processor and memory in some embodiments.Each of the three blocks 110, 120, and 130 may be implemented by thesame, or by different, processors. The three blocks 110, 120, and 130may be in communication with each other and communicate as generallydescribed below.

Data Block

The data block 110 generally provides a set of functionality forbringing databases online in a dynamic manner after systeminitialization, and interacting with those databases. The data block 110may utilize web services to interface with functionality encapsulated instored procedures. FIG. 4 is a schematic illustration of am example ofthe data block 110. A client data agent 141 may communicate with thedata block 110 to generate one or more tables in one or more of thedatabases 150. The client data agent 141 accordingly communicates an XMLschema 160 to the data block 110. The XML schema 160 may be used tospecify desired structure. As will be described further below, the XMLschema 160 may describe desired data characteristics in a way that isgeneric to several database types. The data block 110 may accordinglyreceive the XML schema 160 and format the information from the XMLschema 160 in a manner particular to the type of database for which itis destined. For example, the XML schema 160 may be designed torepresent an entity 162, and the XML schema 160 may contain informationabout attributes of the entity 162 and instructions for and manipulatingthe entity 162. So, for example, the resultant table created in one ofthe databases 150 by the data block 110 may include create, read,update, delete (CRUD) functionality for each of the entities, such asthe entity 162. The CRUD functionality may be created by the data block110 automatically generating a set of stored procedures 165 forregulating interactions with the databases 150. A set of web services167 and 169 are provided in the data block for interaction with theclient data application 140, the client data agent 141, or both.

Accordingly, the data block 110 includes a database code generationfacility at 170. The database code generation facility 170 functions togenerate the explicit database code for one or more of the databases 150corresponding to the desired database structures represented in the XMLschema 160. Data store integration web services 169 are provided tointerface with the client data agent 141. Data block 110 also includesthe stored procedures 165 that may be used to manipulate data in one ormore of the databases 150. In particular, the data block 110 maymaintain a variety of functions for adding additional data sources,structures, or both, including but not limited to: create database,delete database, delete table for entity, create entity, delete entity,update entity, and read entity. Data access web services 167 areprovided for communication with the client data application 140. In thismanner, a flexible web services interface for clients is provided to thedata block 110. By generating database code and storing procedureswithin the data block 110, the specifics of the databases 150 may betransparent to the clients 140. Accordingly any of the individualdatabases 151, 152, and 153 may be changed, or new databases added, orone or more databases removed, without requiring any change to theclients 140. Communication between the data block 110 and the databases150 may occur in any manner. In some embodiments, a traditionalconfiguration file is not used to store connection strings communicatedfrom the clients 140, such as the connection strings 172 and 164.Instead, the data block 110 uses SOAP messages to interact with thedatabases 150. The connections may be specified in SOAP headers, whichmay be secure SOAP headers in some embodiments.

A system 200 implementing an example of a data block 110 according to anembodiment of the present invention is shown in FIG. 5. A generic APIcreates an interface between a client 225 and a data source, such as adatabase 215. A data engine 220 processes messages received by thegeneric API 205 into function calls for the database 215. The genericAPI 205 supports its own abstracted set of commands, such as ‘Execute’as shown in FIG. 5, as will be described in further detail below. Aclient 225 sends a message 230 containing a command supported by the API205 (‘Execute’ as shown in FIG. 3) and a payload. The payload will bedescribed further below but generally contains an XML schema includingone or more references to a specific method supported by the database215. The data engine 220 processes the message 230 and generatesfunction calls 235, 236 for the database 215. In this manner, if themethods of database 215 change, or database 215 itself is swapped outfor a different database having different methods, the generic API 205does not need to be altered or recompiled in any way. Instead, theclient 225 may assemble a different payload for the message 230 asappropriate.

When the database 215 responds to the function call, the data engine 220may format the response in a manner usable by any programming languageable to receive a response from the data engine 220. When the dataengine 220 is implemented as a web-service, for example, the data engine220 will be able to communicate a response to any client 225 capable ofreceiving a web service response. For example, the data engine 220 mayformat a response as a serialized version of an XML schema that can bede-serialized in any client and programming language that can manipulateXML. Information regarding exceptions and errors may also be included inthe returned XML schema response.

An example of a code portion used to implement the generic API 205 mayinclude a generic statement such as:

object ExecuteMethod (string Payload)

This statement indicates the generic API expects an object returned andwill perform an ExecuteMethod procedure using a passed-in payload, whichwill be of a string type and are described further below. The returnedobject may be a serialized form of an XML schema instance, for example.

The generic API 205 may support other methods that are generallyvariations of ExecuteMethod. Other methods may call into ExecuteMethod.The other methods may be specifically for different types of returndata. Return data types may include those specified by ADO.NET, a suiteof data access technologies included in the Microsoft .NET Framework.ADO.NET specifies a variety of possible return types including DataSet,Scalar, XML, DataReader, and None. The generic API 205 may supportfunctions for each of these return types.

The generic API 205 may be implemented as a web service such that theclient 225, or multiple clients (not shown in FIG. 5), can communicatewith the generic API 205 from a remote location using http and SOAPprotocols. SOAP (Simple Object Access Protocol) is an XML-based protocolfor exchanging information and is generic and modular. Accordingly, SOAPmay be advantageous when the message 230 communicated with the genericAPI 205 includes XML, as will be described further below.

The generic API 205 as well as the data engine 220, which will bedescribed further below, may be implemented using any programminglanguage, including any language that supports the implementation of webservices, including but not limited to C#, VB.NET, C++, and Java.

Referring back to FIG. 5, the client 225 develops a payload fortransmission to the generic API 205. The client 225 may be a humanoperator in some embodiments, while in other embodiments the client 225is another computer process which generates the message 230 includingthe payload. While only one client is shown in FIG. 5, any number may bepassing messages to the generic API 205, simultaneously or at differenttimes. Since the generic API 205 supports a generic execute command,such as “ExecuteMethod” in the code portion above, specific methods tobe accessed within the database 215 are provided in the payload. Thepayload should include the names of the methods to be called and anynecessary parameters for calling the methods. The payload is formattedin a manner such that the data engine can process the payload and formatthe information contained in the payload into the function calls 235 and236, for example, for the database 215.

A schematic illustration of an embodiment of a payload 300 is shown inFIG. 6. The schema payload includes a reference to MethodA at payloadelement 355 and reference to MethodB at payload element 360. MethodAincludes references to Parameter1 and Parameter2 at elements 357 and359. A trigger indicator referenced in element 358 indicates an end ofthe parameters for MethodA. The Parameter1 and Parameter2 referenceshave associated metadata including type attributes referenced inelements 361, 363 and values referenced in elements 365, 367. Metadatais information about data and includes the type attributes described.Metadata may also include other information about data. Accordingly,other metadata, such as a direction attribute, may be included in otherembodiments, and some attributes may not be included in otherembodiments of schema payloads. For example, one or more parameters maybe associated with a method in a schema payload that indicates ananticipated return type of the method. The return type parameter willnot have a value associated with it.

MethodB includes Parameter3 referenced in element 370 having type andvalue, referenced in elements 372 and 374, respectively. Triggerindicator referenced in elements 376 indicates an end of the parametersfor MethodB. Any number of methods may generally be referenced in aschema payload, and multiple instances of a same method may be includedas well. The payload 300 may be implemented as an XML schema and codedaccordingly. The trigger indicators 358 and 376 may be implemented by,for example, the end method tags of an XML schema, where element 355, astart of a method reference may be implemented by a <method> tag andtrigger indicator 358 implemented as an </method> tag.

An example of an XML schema that may be utilized as the payload 300 toimplement a “GetCustomer” method using an order number and a purchasedate is as follows:

  <Method Name = “GetCustomer”>   <Parameter Name= “OrderNumber” Type=“int” Direction=   “In”> 123 </Parameter>   <Parameter Name=“PurchaseDate” Type= “DateTime”> 2005-03-18 </Parameter>   <ParameterName= “Return” Type= “int” Direction= “out”>   </Parameter>   </Method>

The above XML schema payload specifies a method GetCustomer containingparameters OrderNumber and PurchaseDate. The OrderNumber parameter inthe schema above is of an integer type. The Direction parameterindicates the parameter passed in has meaning for the call into the API(not the return). In the above example, ‘123’ is the order number beingpassed in. The PurchaseDate parameter in the schema above is of the typeDateTime, and the date 2005-03-18 is being passed to the API. Theparameter Return in the example schema above indicates that a returntype of integer is expected. </Method> is a trigger indicator indicatingan end of the information associated with that method.

Referring back again to FIG. 5, once the payload is received by thegeneric API 205, the data engine 220 processes the payload to formulatespecific function calls 235, 236 for the database 215.

An embodiment of a method 400 for operation of the data engine toprocess the payload 300 is shown in FIG. 7. The payload 300 may beloaded 401 into memory for faster access if desired. In someembodiments, only a portion of the payload is loaded into memoryaccessible to the data engine, and that portion is traversed. The dataengine then traverses 402 the payload by loading a portion of thepayload into memory and processing the portion in memory. As thetraversing proceeds, a next portion of the payload may be loaded intomemory for traversal, and so on, until the entire payload has beentraversed. The data engine can implement a MemoryStream function toexamine the payload from memory. The processed portion is thenoffloaded, and the next portion of the payload may be loaded into memoryand processed. In other embodiments, the payload may be parsed by thedata engine. The data engine parses the payload by validating the entirepayload and loading it all into memory.

Traversing rather than parsing can increase the performance of the dataengine 220. In one embodiment where the data engine 220 is implementedin a Microsoft .NET Framework, the data engine 220 uses an XMLTextReaderto traverse 402 the payload. The traversing operation may not performdata validation typically done when reading XML, and does not parse theXML types as it goes, they are simply read.

As the payload is traversed 402, the data engine 220 identifies 404 thestart of a method call, such as MethodA 355 in FIG. 6. In someembodiments, the actual name of the method call is passed in, such asMethodA 355 and the data engine 220 will utilize this name in thefunction call 235 in FIG. 5 for the database. However, in otherembodiments only a portion of a name of the method call is passed andthe data engine 220 may reformat the name contained in element 355 ofFIG. 6 into an actual function call supported by the database by, forexample, adding suffixes or other characters, as will be describedfurther below. Information regarding how to reformat the name in element355 into a function call name may be included in a data template,described further below.

Once the start of the method call is identified, the data engine 220assembles 406 parameters associated with the method call. Referring backto FIG. 6, for example, Parameter 1 along with its metadata is unpackedfrom the payload 300 and stored as a properly formatted parameter for afunction call. When traversing an XML schema, for example, a storedparameter may be generated for each portion of the XML schema followingthe method indication. The properly formatted parameter may betemporarily stored as objects. As described further below, the storedparameters are communicated to the database, and then they may bediscarded. In some embodiments, the data engine may check the storedparameters to determine if the parameters are complete, and if aparameter is missing an element, or if the method name is faulty, theinformation related to the faulty method or parameter in the payload maybe discarded or skipped.

As the data engine continues to process the payload, a trigger indicatoris then identified 408, such as the indicator 358 in FIG. 6. Once thetrigger indicator is identified, the data engine 220 calls 410 theidentified method using the parameters assembled 406. The data engine220 then identifies 404 a next method call in the payload, and theprocess shown in FIG. 7 may repeat.

Structurally, embodiments of the data engine 220, shown in FIG. 5, mayinclude a processor coupled to a computer-readable medium containingexecutable code causing the processor to perform any or all of theactions shown in FIG. 7 and described with reference to FIGS. 4-6. Thedata engine 220 may be implemented in software, hardware or combinationsthereof. Embodiments of the data engine 220 may be implemented as a webservice and accessed using http, including the use of SOAP transport forcommunicating XML. The processor implementing the data engine 220 may bethe same as that implementing the generic API 205 in some embodiments.

Accordingly, the above description has provided an explanation of how adata engine may support a generic API to receive messages including apayload and process the payload into one or more specific function callsto a database. By providing a generic API, the generic API need not berecompiled or rewritten when one or more client entities want tocommunicate new or different calls to the API. However, as describedabove with reference to FIG. 1, existing APIs are coded to formatfunction calls in a particular language depending on the type ofdatabase for which the call is destined—such as Oracle, SQL, or thelike. The data engine 220 may also provide functionality to flexiblyformat function calls for any of a variety of databases as will now bedescribed. In this manner, the generic API 205 also need not berecompiled or rewritten if the type of target database changes.

When a data engine receives a payload destined to apply to a certaintype of target database, the data engine can formulate the method callsto the target database in a manner specific to the type of the targetdatabase. Database types may include, for example, Oracle, SQL, or anyother database type or format. To do this, the data engine shouldreceive an indication of the target entity. With reference to FIG. 5, anindication of a target database type 250 may be communicated by theclient 225 to the data engine 220. The data engine 220 may receive thetarget type indication 250 in a variety of ways. In one embodiment, thedata engine 220 identifies the type of database by reading aconfiguration file accessible to the data engine. For example, when thedata engine is implemented as a web service, a connection string to anyOLEDB (Object Linking and Embedding Database), including Oracle and SQL,may be used as a web.config setting. The data engine web service couldthen read the web.config setting at each call, or at other periods insome embodiments. In some embodiments, the data engine determines thetarget database type by referencing the configuration file on a defaultbasis. That is, if no other target database indication is provided, thedata engine may use the target database type specified in aconfiguration file accessible to the data engine.

In other embodiments, the indicator 250 of the target database type istransmitted in parallel with the message 230. When the client 225communicates with the data engine 220 over http, a SOAP header may beused to pass the indicator 250. The SOAP header can be inspected on acall-by-call basis. The SOAP header may be prepared using a connectionstring in a configuration file residing with the client 225. The dataengine may inspect the SOAP header to determine the type of the targetdatabase on every call, in some embodiments or periodically according tothe particular implementation and use of the data engine.

When the type of database to be involved changes, the client 225 canchange the indicator 250 or transmit a new indicator 250 withoutchanging the message 230 or the process of communicating the payload.The SOAP header or configuration file is simply updated to indicate thenew or different target database. The data engine 220 uses the targettype indicator 250 to change the way data unpacked from the message 230is formatted into individual calls 235, 236 to the target database.Thus, formulating a request to a new or different database type does notrequire recompilation of any code within the data engine. The type oftarget can thus be changed without changing the payload or re-compilingthe generic API executed by the data engine. A new template may simplybe used, as described further below, that allows the data engine 220 toformat the call in a manner appropriate for the new target type.

To facilitate formatting function calls in accordance with any of avariety of possible database types, as indicated by the target type 250,templates are provided in a template memory 260 in communication withthe data engine 220. The template memory 260 may be integral with acomputing system used to implement the data engine 220, or may be aseparate data storage subsystem. The template memory 260 containstemplates describing how method calls are formatted for each of avariety of database types. In some embodiments, the template furtherdescribes how data may be manipulated within each database (for example,create, read, update, delete and other operations). The data templatemay describe how each operation maps into specific commands for thetarget database type. Data templates may be implemented as XML schemas.In some embodiments, the data templates advantageously require a smallamount of memory such that they are able to be stored in cache memory.Of course, the size of the cache memory will be dependent on theavailability and cost of the memory. As an example of the size of a datatemplate, in some embodiments, a data template suitable to preparemessages for a SQL server is less than 4 kilobytes.

Any number of data templates may be provided, with typically one datatemplate per database type with which the data engine may have to accessor communicate. In some embodiments where certain functions of differentdatabase types are identical, the database types may share a single datatemplate. Data templates may be deleted when a certain database type isno longer needed or desired. Data templates may be added when a databasetype is added or anticipated. Accordingly, when a destination databasetype changes, or a new database is added, a new template may simply beadded to the template memory 260 without a need to recompile the genericAPI 205 or change the operation of the data engine 220.

An embodiment of a method 500 implemented by the data engine 220 togenerate a function call is schematically depicted in FIG. 8. The dataengine receives 501 an indicator of the target type, as described above.The data engine may then load 503 a data template corresponding to thetarget type into a cache or other accessible memory for faster access.If the data template has already been loaded due to a pre-loadingprocedure or recent use, for example, the data template need not bereloaded. Alternatively, the data engine could access the data templateat a remote location without loading the template into the cache.

The data engine then traverses 504 the data template, to unpack thetemplate 506 and generate statements specialized to the database type.The statements 506 are then used by the data engine in combination withdata received in the payload, described above, to generate a method callfor the database, as generally described above with reference to FIG. 7.That is, with reference to FIG. 7, once the data engine has identified amethod call and assembled parameters from a payload, the data engine mayutilize database specific statements generated from a data template togenerate an appropriate method name for the target database and formatparameters for the target database. So, for a single input payload, thedata engine could generate any of a variety of statements, based on thedata template used to format the information extracted from the payload.

Accordingly, embodiments of data engines and generic APIs have beendescribed above that allow flexible communication with a variety ofdatabases. Any method call may be handled by the generic API withoutrecompilation, at least in part because the data engine extractsspecific method names from a payload. Additionally, the payload may beformatted for any destination database type in accordance with datatemplates. Embodiments of data engines according to the presentinvention may provide functionality beyond the formatting of methodcalls, however, to include an auto-generation functionality. The dataengine itself may perform the auto-generation functionality in someembodiments, or a separate auto-generation engine may be providedoperating on a same or different processor than the data engine.

As known, databases may contain various database-specific objects thatimpart additional functionality to the database. An API specific to thedatabase type has been traditionally required to access or utilize thesedatabase-specific objects and a database administrator was typicallyrequired in prior systems to generate new objects in a target database.However, an embodiment of an auto-generation engine according to thepresent invention may generate data templates for any database object,allowing their use by the data engine as described above. Additionally,using embodiments of a data engine and auto-generation engine, such asthe auto-generation engine 290 in FIG. 5, objects may be automaticallygenerated in a target database, including tables, procedures, indicesand triggers. In this manner, new objects and entities can be supportedwithout specific database administrator intervention.

To facilitate auto-generation functionality, one or more databasetemplates for the implementation of commands in a target database aregenerated. These templates describing command implementations may be XMLschemas and may be stored in the template memory 260 in FIG. 5.Alternatively, the templates may be stored in one or more targetdatabases or other content-management system. An embodiment of a method600 for creating a template for database commands is shown in FIG. 9.One or more commands are identified for implementation 610. Generally,any command supported in an API may be manipulated according to themethod 600 of FIG. 9 by analyzing the command, identifying and retainingstatic content and replacing variables with placeholders. Accordingly,to identify commands 610, commands of interest are selected from aparticular API. For example, some database types (such as Oracle)support various APIs or versions of a database engine, and some (such asSQL) support various language syntaxes. Generally, any API and/or syntaxmay be supported according to embodiments of the present invention. Theparticular commands identified 610 may include, for example, create,insert, retrieve, select, update, procedure, trigger, index, function,getmail, sendmail, and the like.

A template is then be generated 620. The template may be an XML schemaincluding an element for each command identified. Any XML editor orother program may be used to generate the statement template, such asVisual Studio XML Schema Editor or XMLSpy. Each command identified 610will be included as an element in the template. An example of a databasetemplate 650 is shown in FIG. 10. A statement 655 of the template 650includes a formatted command 660 with placeholders for the variableinformation. The statement 655 also includes a reference 665 to one ormore placeholder templates describing how to format information toreplace the placeholder contained in the formatted command 660. Thedatabase template 650 further includes a placeholder template 670. Theplaceholder template 670 includes a format 675 and a fieldmask 680 whichtogether will describe how to generate a string using input data toreplace the placeholders in the formatted command 660. Although only onestatement 655 and placeholder template 670 are shown in FIG. 10, anynumber may be generated.

Once the template 650 is generated including elements for each desiredcommand and elements for each placeholder, referring back to FIG. 9, thetemplate is included for placeholder formatting 630 and then stored 640in a location accessible to the auto-generation engine. The templatesmay be stored in the file system, or in some embodiments, in a databaseor a content-management system. The templates will be used subsequentlyas described below to generate objects within various target databases.

Once templates are generated as described above and with reference toFIGS. 8-9, a processing engine, such as the data engine 220 may utilizethe template to generate structures in a target database. By utilizingthe templates, a client or other transmitting entity can cause astructure or procedure to be stored in a database, without requiringknowledge of the particular syntax necessary to create the structure orprocedure in the database.

Operation of an auto-generation engine is described with reference toFIG. 11, and a detailed example of one embodiment is provided below. Apayload is received 710. The payload is similar to data payloadsdescribed above and depicted in FIG. 6, but contains differentinformation. An example of a payload 750 is shown in FIG. 12. Thepayload 750 is an XML schema containing an entity name element 755 and aplurality of attribute elements 760-62 associated with the entityelement 755. Each of the attribute elements 760-62 may include one ormore parameters. Although only one entity element 755 is shown in thepayload 750, a number of elements may be included, and each element maygenerally have any number of attributes.

Following a call into the generic API and the receipt of the payload 710(FIG. 11), an appropriate database template is loaded 720 into memory.As described above with respect to the data engine and data templates,an indication of the target database type may be received in a varietyof ways, for example by loading a web.config file or by inspecting SOAPheaders. The template may be loaded from cache, or if not in cache, thetemplate may be loaded from the file system or any other storedlocation, including a statement template repository which may be thesame or different than the template memory 260 in FIG. 5. Theauto-generation engine prepares completed statements 730 for executionby looping through the database template 650 of FIG. 10. Placeholders inthe formatted statement 660 are replaced with information from thepayload 750 of FIG. 12 as directed by the placeholder templates 670.Generally, the format element 675 of the placeholder template 670provides a format, including any delimiting characters or other syntax.The fieldmask element 680 specifies which parameters of the attributes760-762 from the payload 750 of FIG. 12 should be inserted into theformat 675 and in which order. Parameters from each of the attributes760-62 are formatted according to the placeholder template 670 andreplace the placeholder in the formatted statement 660. Once allplaceholders are replaced and the statement is complete, the statementis executed 740, referring back to FIG. 11, generating objects in thetarget database. The statement is executed in one embodiment by theprocessing capabilities of the target database. In another embodiment,the auto-generation engine executes the statements, generating theobjects in the target database. For example, a table, procedure, emailfolder or PL SQL package may be stored in the target database inaccordance with the executed statements. Once stored in the targetdatabase, the objects may be populated, called, or otherwise used by anyprocess, including a data engine, as described above.

A detailed example of operation of an embodiment of an auto-generationengine is now described to aid understanding.

A XML schema used as a payload passed to the auto-generation engine mayinclude:

  <EntitySchema Entity=“Provider” xmlns=“http://tempuri.org/  DBSchema.xsd”>   <Attribute Name=“ProviderID” Type=“uniqueidentifier”Size=“”   Null=“NOT NULL” Default=“DEFAULT (NEWID( ))” ID=“0”  Key=“NonKey” />   <Attribute Name=“ProviderName” Type=“nvarchar”Size=“(50)” Null=“NOT NULL”   Default=“DEFAULT (‘Name’)” ID=“1”Key=“NonKey” />   <Attribute Name=“ProviderDescription” Type=“nvarchar”Size=“(255)” Null=“NOT   NULL” Default=“DEFAULT (‘Provider’)” ID=“2”  Key=“NonKey” />   − <Constraint ConstraintString=“” Type=“PRIMARY  KEY” TemplateID=“9”>   <Format>,CONSTRAINT PK_ut{0} PRIMARY KEYCLUSTERED ({1})</Format>   <AttributeID>0</AttributeID>   </Constraint>  </EntitySchema>

The above payload is designed to trigger the creation of a “Provider”entity in a target database. The attributes of the “Provider” entity are“ProviderID, ProviderName and ProviderDescription.” Each attribute has avariety of associated parameters, as listed in the payload.

A first statement in a database template used to process this payloadmay include:

<Statement HasConstraints=“true” HasBusinessRule=“false”> <Format>createtable ut{0} ({1} {2})</Format> <Attributes ID=“0” AttributesString=“”TemplateID=“0” /> </Statement>

The formatted statement is “create table ut” with various placeholdersindicated between the { } brackets. The first {0} placeholder isreplaced with the entity name “Provider”. The Attributes ID andTemplateID specifies how to process the attributes of the payload forinsertion into the {1} placeholder. Here, the TemplateID 0 will be usedto process the attributes.

TemplateID 0 may be contained as an element within the template and mayinclude:

<Template ID=“0” Sepparator=“,”> <Format>{0} {1}{2} {3} {4}</Format><FieldsMask>:Name,Type,Size,Null,Default</FieldsMask> </Template>

For each attribute, this template will be used to format the attribute'sparameters by replacing the placeholder in the format statement with thepayload information corresponding to the fieldsmask indicator. In theexample above, for the ProviderID attribute, this would result in“ProviderID uniqueidentifier <Size not specified> NOT NULL DEFAULTNEWID( )”. A similar string is generated for each attribute, and thecollection of strings is used to replace the {1} value in the createtable template statement, above.

A next statement in the template may be:

<Statement HasConstraints=“false” HasBusinessRule=“false”><Format>create procedure uspCreate{0} ({1}) AS INSERT INTO ut{0} ({2})VALUES ({3})</Format> <Attributes ID=“0” AttributesString=“”TemplateID=“1” /> <Attributes ID=“1” AttributesString=“” TemplateID=“2”/> <Attributes ID=“2” AttributesString=“” TemplateID=“3” /> </Statement>

The placeholder {0} is replaced with the entity name from the payload,“Provider”, resulting in “create procedure uspCreateProvider”. Then, theattributes (ProviderID, ProviderName, ProviderDescription) are processedaccording to TemplateID 1, as indicated by the Attributes ID line forinsertion into the {1} placeholder. TemplateID 1 may include:

<Template ID=“1” Sepparator=“,”> <Format>@{0} {1}{2} {3}</Format><FieldsMask>:Name,Type,Size,Input</FieldsMask> </Template>

This results in a string being generated for each attribute in thepayload as described above. For ProviderID, the string would be“@ProviderID uniqueidentifier IN”. The strings generated with eachattribute are concatenated and inserted into the {1 } placeholder. Thenext placeholder in the statement is processed according to Template ID2 which may include:

<Template ID=“2” Sepparator=“,”> <Format>{0}</Format><FieldsMask>:Name</FieldsMask> </Template>

The string generated for ProviderID would simply be “ProviderID”. Thestring generated for each attribute is concatenated and inserted intoplaceholder {2}.

The attributes are then processed according to Template ID 3, which mayinclude:

<Template ID=“3” Sepparator=“,”> <Format>@{0}</Format><FieldsMask>:Name</FieldsMask> </Template>

The string generated for the Provider attribute would be “@Provider”.Again, the strings for all the attributes are concatenated and insertedinto the {3} placeholder. Ultimately, after replacing all placeholdersthe overall statement created will be:

create procedure uspCreateProvider (@ProviderID unigueidenfifier IN,@ProviderName nvarchar(50) IN, @ProviderDescription nvarchar(255) IN) ASINSERT INTO utProvider (ProviderID, ProviderName, ProviderDescription)VALUES (@Provider, @ProviderName, @ProviderDescription)

This statement can be executed to generate a procedure in a targetdatabase. This procedure may later be used by other engines or programsaccessing the database. This alleviates the need for a databaseadministrator to manually establish the procedure in the database. Oncethe information is passed to the API as a payload, the auto-generationengine automatically creates the appropriate procedure in an enddatabase.

Embodiments of the present invention provide data handling platforms,which may be included in system 800 shown in FIG. 13 including orrunning an embodiment of a data engine 220 as described herein. The dataengine 220 may include one or more processors or other computationalcores that process requests received from any type of client, includingclients 821, 822 and 823 in FIG. 13. The clients may include, forexample, a user through a user interface, or some other process, programor machine transmitting information to the data engine 220. Any of therequesting entities 821, 822 and 823 may communicate with the dataengine over any known means of communication, wired or wireless,electronic or optical. In some embodiments, the sending entity maycommunicate with the data engine over http and utilize SOAP headers, asdescribed above. Embodiments of data engines described herein, such asdata engine 220, may advantageously be implemented as a web service.Generally any programming language may be used, including any languagethat supports the implementation of web services, including but notlimited to C#, VB.NET, C++, and Java. Implementing the data engine as aweb service allows any transmitting or receiving entity to communicatewith the data engine easily in a well-known, scalable manner. The dataengine 220 is able to process incoming messages according to embodimentsof methods described above with reference.

One instance of the data engine 220 is sufficient in some embodiments toservice any number of sending entity requests to any number of availabledatabases. Three available databases, 831, 832 and 833 are shown in FIG.13. Of course, the number of clients, databases, and requests to beserved is a function of the ultimate application of the system and speedof the processor(s) used by the data engine, as well as the speed of thecommunication interfaces. Embodiments of the data engine may generallybe implemented to interface with any system-level software platformsincluding, but not limited to, Windows, Linux and Java. Memory 840, orother computer-readable medium, may be coupled to or form part of thedata engine 220. The memory 840 may contain the executable code causingthe data engine 220 to perform the various functions described herein.Further template memory 850 stores data templates as described above.The template memory 850 may be separate from the memory 840 or they maybe combined. A cache (not shown) may also be coupled to the data enginefor storing loaded templates from the template memory 850, although insome cases the cache may be included in the memory 840 or the templatememory 850 itself.

As was described generally above with reference to FIG. 3, the dataengine may be part of a larger data handling platform 100 in someembodiments—with other portions of the data handling platform providedto communicate messages, and take action on the data. To communicatewith other components of the data handling platform 100, the data block110 may be configured to publish messages to a shared message bus, aswill be described further below, and may be subscribed to receivecertain types of messages that may be published by other components orsystems to a shared message bus. For example, in some examples, when thedata block 110 stores a new data item, it may publish a messageindicating that a new data item has been stored. Other systems orcomponents that may need to take action based on that data item aresubscribed to that type of message, and may be so notified by amessaging block, examples of which are described below.

Messaging Block

Examples of a data block have been described above that may facilitateinteraction with one or more database types in a generic manner. Thatis, the data block provides the specific interaction with an enddatabase. The client need not know, or provide software code specificto, the end database to be manipulated. Referring back to FIG. 3, thedata block 110 may accordingly provide an interface between one or moreof the clients 140 for placing data into one or more of the data sources150. One or more of the clients 140 may want to communicate with oneanother, such as by calling software procedures that one or more of theclients 140 provides. As was generally described above, a typicalsoftware approach to hard coding interactions between one or more of theclients 140 may limit the ability of the system to change withoutrequiring significant code rewrites. Accordingly, a message brokercapable of calling methods independent of the syntax of the end systemcalled may be used. The messaging block 120 may provide such a messagebroker functionality.

FIG. 14 is a schematic illustration of a messaging block 120 accordingto an embodiment of the present invention. The messaging block 120includes a message bus 1310. Generally, the message bus 1310 facilitatescommunication between one or more clients, such as the clients 140 b and140 c by receiving messages, persisting messages, and reporting messagesto interested subscribers. In this manner, communication is centralizedand need not occur directly between the clients 140 b and 140 c. Rather,communication is routed through the message bus 1310. The message bus1310 may include one or more processors for implementing thefunctionalities described. The message bus processors, as describedabove, may be shared in some embodiments with the data block 110 and therule block 130. The message bus 1310 may further include memory for thestorage of messages, as will be generally described below. The messagebus 1310 may be implemented in some embodiments as an API performing thefunctionalities described.

Event schemas 1315 are stored in a memory accessible to or part of themessage bus 1310. Each of the event schemas 1315 provides associateddatabase infrastructure so messages received of the event type specifiedin the schema may be created and utilized by one or more publishers1320. Each of the event schemas 1315 may accordingly come to beassociated with one or more of the publishers 1320. The publishers 1320are stored data structures representing a source of an event or message.So, for example, if the client 140 b will be sending messages to themessage bus 1310, the client 140 b may establish one or more publishers1320. Publishers 1320 may be stored in the form of XML arrays tofacilitate the use of SOAP in embodiments of the present invention. Apublisher may be notified by the message bus 1310 of responses to thepublishing of an event. Accordingly, a uniform resource identifier (URI)or other mechanism for notifying a publisher may be stored.

Publishers may create a message by calling a publisher subscriber webservice “CreateEvent”. The web service may be implemented by themessaging block 120. An entry may be made in a specific event tablerelated to an event schema. A trigger on the event table inserts datainto a notification table that may include a time dispatched. Themessage bus 1310 may include a router that polls for the notifications1335 and ensures that messages are dispatched in a timely fashion.

Subscribers 1325 are data structures containing information about adestination of a message or event. Similarly to publishers, 1320, eachsubscriber 1325 may include a uniform resource identifier (URI) or othermechanism for notifying a subscriber. For example, the URI for asubscriber may be a web page where a subscriber manages a plurality ofsubscriptions. So, for example, a client interested in receivingmessages from the message bus 1310 may establish one or more subscribers1325. Each of the subscribers 1325 may be subscribed to messages fromone or more of the publishers 1320. Subscribers 1325 may be stored inthe form of XML arrays to facilitate the use of SOAP. Accordingly,clients interested in passing messages to the message bus 1310 mayestablish one or more publishers 1320 capable of publishing eventshaving a type corresponding to one or more of the event schemas 1315.Clients interested in receiving messages from the message bus 1310 mayestablish one or more subscribers 1325. A client may establish bothpublishers and subscribers to both send and receive messages.

To notify one or more subscribers 1325, a message bus router included inthe message bus 1310 may call a notify function of an event notificationweb service. A notification URI may be overridden with a subscriptionURI for each event. In return, subscribers 1325 may call anacknowledgement web service to acknowledge receiving the message.

A message received from a publisher 1320 may be stored at the messagebus 1310. The entire message may be stored, or in some embodiments, onlyevents 1333 contained in the message are stored, as will be describedfurther below. The message bus 1310 determines where to send the messagebased on subscriptions 1330. The subscriptions 1330 are data structurescontaining information about a subscription, that may refer back to asubscriber and a type of message the subscriber is interested inreceiving, such as one or more of the event schemas 1315. Otherinformation, such as a filtering mechanism, may also be included in thesubscriptions 1330. The message bus 1310 may maintain the subscriptions1330. Individual subscriptions may be added or deleted without alteringor interrupting the general functionality of the message bus 1310. Byadding a new subscription, or altering a subscription stored in thesubscriptions 1330, the message bus 1310 will begin to route messagesdifferently, without any of the code for the operation of the messagebus 1310 having to be altered. By way of summary, the message bus 1310receives a messages, stores at least part of the message, consults thesubscriptions 1330 to determine which subscribers 1325 are interested inmessages of the type received, and then generates notifications 1335 forthe interested subscribers. Accordingly, while clients may be affectedby the content of messages, they may pass messages only to and from themessaging block 120 in embodiments of the invention, and may not need tocommunicate with any other client directly. In some embodiments of thepresent invention clients may never communicate with other clientsdirectly, and all communication may be routed through the messagingblock 120.

By storing messages, or portions of messages, at the message bus 1310and verifying notifications 1335, the message bus 1310 may ensure thatcommunication is accurate and continuous. Furthermore, by storing theevents 1333, scalability and fault tolerance of the system may beimproved relative to a system where such information is not persisted.For example, storing messages may prevent or reduce the incidence oflost messages due to a failure of communication with a particularclient. Instead, the message may be stored until it may be properlydelivered. Publishers and subscribers may expose functionalitycorresponding to object methods as web services. Objects that accessthese methods may be shared across clients as similar objects expressedas serialized XML and translated to language specific objects as neededby clients.

Accordingly, clients may communicate messages to the message bus 1310.The messages may be SOAP messages in some embodiments. FIG. 15 is aschematic illustration of a message 1400 according to an embodiment ofthe present invention. The message 1400 includes an event identifier1410. The event identifier specifies the type of event, and maycorrespond to one of the event schemas 1315 of FIG. 14. The message 1400further includes a decoder XML schema 1415. The decoder XML schemaindicates how to decode the message 1400. That is, when the message bus1310 receives the message 1400, the message bus 1310 may decode themessage 1400 in accordance with the decoder XML schema 1415. The message1400 further includes XML content 1420. The XML content 1420 describesthe event, and may be wrapped in a CDATA section, such that it may notbe processed itself by the message bus 1310. The generation andprocessing of messages includes the generation of XML schema contentthat may in some embodiments be analogous to the generation andprocessing of XML schema content described above with respect to thedata block 110. The message 1400 further includes a publisher identifier1425 that may include a URI corresponding to the publisher having postedthe event. Messages and notifications sent by the message bus 1310 toclient systems may have an analogous structure. In some embodiments,messages may be encrypted so that only authorized subscribers or clientmay access messages. Generally, any encryption methods may be used.

The messaging block 120 may include an API that implements a variety offunctionalities to maintain the publishers, subscribers, andsubscriptions described above with reference to FIG. 14. For example, anAPI implemented by the messaging block 120 may include, but is notlimited to, some or all of the following procedures: CreatePublisher,ReadPublisher, DeletePublisher, CreateSubscriber, ReadSubscriber,DeleteSubscriber, CreateSubscription, ReadSubscription,DeleteSubscription, and CreateEvent. In one example, a user at a clientmay prepare an XML payload representing a publisher, subscriber, orsubscription schema. The user then selects a function of the API, suchas CreatePublisher, to operate on the XML payload. A simple userinterface may be provided at the client system to facilitate this entry,which may include a text box for entry of the XML payload and aplurality of buttons corresponding to each of the methods implemented bythe API, such as “CreatePublisher.” Once selected, the API mayde-serialize the XML instance entered by the user into an appropriateobject of a code type used by the messaging block 120, such as, but notlimited to, C#. The API is again called using the generated object, andappropriate objects for the messaging engine 120 may be created. Forexample, the API of the messaging block 120 may then return an XMLresult of the call and update the XML payload with any specific objectnames and formatting used by the messaging block 120, the message bus1310, or both, in processing the request represented by the XML payload.For example, the XML payload may be processed by any of the methodsimplemented in the API to have the syntax usable by any type ofmessaging engine, such as a BizTalk messaging engine. Because the APIproviding the object names and syntax is implemented by the messagingblock 120, the client system 140 b and 140 c need not be aware of theparticular syntax or object names in order to establish a publisher,subscriber, or subscription. Detailed code examples of methodsimplemented by the API are provided below in the examples section. Theexamples are not intended to limit the use of the messaging engine 120to any particular software language, database type, or messaging system.Rather, the examples illustrate how to implement the describedfunctionality in one particular environment as an aid to understandingand appreciating how the methodology may also be extended to otherenvironments, software languages, and messaging systems.

The messaging block 120 may communicate with the data block 110 formanaging one or more data tables containing the notifications 1335,events 1333, publishers 1320, subscribers 1325, or subscriptions 1330.That is, in some examples, the data block 110 may be used to generatedatabase tables for the events 1333, publishers 1320, subscribers 1325,subscriptions 1330, or combinations thereof. Recall, as describedgenerally above, the data block 110 may create and manipulate tables inan automatic manner based on stored templates. Accordingly, templatesmay be stored particular to the storage, use, or both, of the messageblock components shown in FIG. 14. In this manner, stored software codeused by the messaging block 120 may be auto-generated and stored by thedata block 110 using one or more stored templates. Similarly, the datablock 110 may be used to generate or process messages published to orreceived on the messaging bus. For example, with reference to FIG. 5,the data engine 220 may execute a message in an analogous manner toexecution of a payload 230. That is, in some examples, all or a portionof the message may serve as a payload for the data block 110.

An example of a system 1500 utilizing an embodiment of the messagingblock 120 is shown in FIG. 16. An example of establishing an accountwill be described. In the system 1500, a variety of client systems makeuse of account information including an order management system 1505that may record orders associated with an account, a billing managementsystem 1510 that may process billing and payment information associatedwith an account, a customer management system 1515 that may process andrecord interactions associated with an account, and a trackingmanagement system 1520 that may track all messaging traffic for anentire enterprise. Each of the systems 1505, 1510, 1515, and 1520 may beco-located or in disparate locations, and may in some embodimentsoperate in part on a same computing device, although different computingdevices may be used. A user interacts with the system 1500 through auser interface 1525. The user interface 1525 may be separate from thesystems 1505, 1510, 1515, and 1520 as shown, or may be an integral partof any or all of those systems. Further, the user interface 1525 mayindicate an interface with an actual user, system administrator, or witha computer process that serves as the user as described. The userinterface 1525, as well as the systems 1505, 1510, 1515, and 1520 are incommunication with the messaging block 120.

As another example, referring to FIG. 16, a method for adding thebilling management system 1510 to the system 1500 will be described. Apublisher is created in the messaging block for the billing managementsystem 1510 using a publisher schema. An event schema is created foreach of the events of interest that may occur inside of the billingmanagement system 1510, such as but not limited to change billingaddress, add billing address, update balance owed. One or moresubscribers may be created for each of the created events. For example,if the administrator is aware that the customer management system 1515would like to subscribe to one or more of the events, a subscriber mayaccordingly be created. For each subscriber, a subscription may becreated for implementing the delivery of a notification in thesubscribing system. In some examples, the billing management system 1510itself may be modified for use in the system 1500 coupled to themessaging block 120. For example, a processor or computer systemimplementing the billing management system 1510 may execute additionalsoftware including instructions to call a method CreateEvent and post anXML payload describing a billing change, or other event. Existingsoftware executed by the billing management system 1510 may be modifiedfor this purpose by, for example, identifying locations in the softwarecode executed by the billing management system 1510 where events may beposted. These code locations may then be modified to post events usingthe CreateEvent method.

In some examples, it may not be desirable or possible to alter softwarecode being executed by a system, such as the billing management system1510. Accordingly, in some embodiments messages may be generated by thebilling management system 1510 in a manner that does not requirealtering software code being executed by the billing management system1510. For example, the billing management system 1510 may be, prior tointerfacing with the messaging block 120, coupled to a database 1512 forstoring billing information or other data maintained by the billingmanagement system 1510. In one embodiment, for integration with themessaging block 120, a trigger may be added to the database 1512 thatwould post a change to the database 1512 into a message queue. Theposting may be accomplished through, for example, a C# Assembly loadedin the database engine running on the database 1512, or through a storedprocedure in the database 1512. Accordingly, the software code executedby the billing management system 1510 itself may not require alteration.In other examples, changes to the database 1512 may be stored in anotherdatabase (not shown), another table, or another file system. In stillanother example, a web service call may be made that would post databasechanges directly to the message bus of the messaging block 120. In theseexamples, a Windows service, web service, or other process called by themessage bus, may access the changes and create an event to be persistedon the message bus of the messaging block 120.

That is, a generic Assembly may be prepared having a method acceptingXML as input and includes code that, when executed, maps the XML into anevent payload and pushes the payload to either a message queue or themessage bus. The Assembly is deployed in the database 1512. Anadministrator of the billing management system 1510 may then postchanges to certain, or all, entities, to the method call of the Assemblydeployed in the database 1512. In this manner, an intermediary systemmay be placed between the billing management system 1510, the database1512, or both, that generates events corresponding to changes of thedatabase 1512. In this manner, software code executed by the billingmanagement system 1510 may not require alteration or recompilation.

The examples described above may still require some cooperation on thepart of a system administrator for the billing management system 1510,even if the code itself may not require alteration or recompilation. Insome examples, however, systems may be integrated with the messagingblock 120 without such cooperation. In particular, a trigger may begenerated in each table in the database 1512 corresponding to an entityof interest to the system 1500. A generic assembly may be written havinga method that accepts XML and maps the XML to an event payload, andpushes the event to either a message queue in the database 1512 or themessage bus of the messaging block 120. The assembly is then deployed inthe database 1512. The trigger previously generated in each table callsthe assembly and method to generate the events. Then, as above, anintermediary between the messaging block 120 and the database 1512pushes the events onto the message bus of the messaging block 120. Byusing triggers in tables of the database 1512, no identification ofentities of interest may be required within the billing managementsystem 1510.

In still other examples, access may not be feasible for changes toeither the billing management system 1510 or the database 1512. Rather,the billing management system 1510 may provide only a procedure allowingchanges to entities to be obtained. To capture messages generated by thebilling management system 1510 in this example, a different approach maybe used. A polling event schema may be created in the messaging block120. A publisher for the polling event schema may be created in themessaging block 120 corresponding to the message bus. A subscriber maybe created in the messaging block 120 corresponding to the polling eventschema. A subscription may be created in the messaging block 120 for thesubscriber. The subscription may be a recurring subscription with aperiodic renewal time, such as five minutes. A web service endpoint maybe created in the messaging block 120 itself specifying the location ofthe subscription as an endpoint. The messaging block 120 may call theprocedure provided by the billing management system 1510 to receivechanges. The changes may be processed into an appropriate XML event andposted to the message bus.

FIG. 17 is a flowchart illustrating a method for setting up themessaging block 120 to pass account messages between an account creatorand the systems 1505, 1510, 1515, and 1520 of FIG. 16. The flowchartfurther describes a method for passing account messages. An event schemais created 1602 to describe an account event. A publisher of an accountevent 1605 is created. Subscribers are also created 1610 associated witheach of the systems 1505, 1510, 1515, and 1520. As generally describedabove, the publishers and subscribers may be XML instances for each ofthe corresponding systems, including a system used to create accounts.Subscriptions are then created 1615 to subscribe the systems 1505, 1510,1515, and 1520 to account events. As generally described above, thepublishers and subscribers may be implemented as XML instances. Thecreation 1602, 1605, 1610, and 1615 may take place as part of an initialset-up of the messaging block 120 implementation of FIG. 16.

In use, a user may create 1620 an XML payload corresponding to accountinformation. The XML payload may be created in any suitable manner, suchas by utilizing a web application containing all fields of an account ora wizard that may collect information for an account. Other methods maybe used in other embodiments. The user's system may then pass 1625 amessage including the XML payload and an indicator that the messagecorresponds to an account event to the messaging block 120. Themessaging block 120 may then query the subscriptions and identify 1630subscribers to account events and generate notifications for thesubscribers. Should a new system be added to the implementation of FIG.16, and the new system also function to utilize account information, thenew system may also receive notification of account events by creating acorresponding subscriber entity and subscription with the messagingblock 120.

Accordingly, embodiments of messaging blocks according to the presentinvention may provide a publish and subscribe engine that may allowsystems to access information generated by other systems in a genericmanner independent of system type. Indeed, neither the system generatingthe message, nor the systems receiving the message, may need to knowanything about the type or style of the originating or destinationsystem. Instead, the communication is facilitated by the messagingblock, allowing systems to be added, removed, or changed, in a flexiblemanner that may not require altering or re-compiling the software codethat operates the messaging block itself. The messaging block 120 mayalso facilitate communication within the platform 100. The data block110 and rule block 130 may subscribe to and publish messages on themessage bus. Referring back to FIG. 2, any of the other componentsresident in the intelligence layer 60, adaptive layer 55, or core layer50, may also publish message on, and receive notifications from, themessage bus. In this manner, the messaging block 120 serves as amediator of communications for the platform 100.

Rule Block

Referring back to FIG. 3, examples of the data block 110 and themessaging block 120 have been described above. Briefly, the data block110 facilitates data storage and interaction with data sources 150 in ageneric manner. The messaging block 120 facilitates message passingbetween one or more of the clients 140 in a generic manner. Accordingly,the platform 100 provides a flexible system for managing interactionsbetween and among the clients 140 and the data sources 150. It may bedesirable to act upon the data gathered and stored by the platform 100,also in a generic manner. Accordingly, the rule block 130 may beprovided to evaluate rules dynamically through message passing.

An example of operation of the rule block 130 will be described withreference to FIG. 18. One or more rules, such as the rule 1705, may bemaintained by the client 140. An XML document 1710 describing the rules1705 is communicated to the rule block 130. Rule schemas described bythe XML document 1710 may be defined during run time, or at start up. Insome examples, rules may be inferred. That is, a rule may be generatedin an automated fashion based on interactions or data available to theplatform. For example, rules may be inferred based on an entity'sinteraction with different computing devices. Rules may also be inferredbased on contextual information about an interaction. For example, if anentity sets a room temperature to seventy degrees at a certain timewhile the outside light was at a certain level, a rule may be inferredand stored with the rule block 130 that if it is a certain time and theoutside light it at a certain level, an action to set the innertemperature to seventy degrees should be taken. Other types of rules maybe inferred using other information available to the platform.

As with other blocks described above, communication with the rule block130 may occur through SOAP messaging to a Web service implemented by therule block 130. The XML document 1710 generally will include an if/thenstatement. The “if” statement may specify a condition, while the “then”statement may specify an action to be taken on satisfaction of thecondition. The statements may reference data stored in one or morelocations accessible to the rule block 130. Accordingly, the rule block130 may access one or more data stores to retrieve information used toevaluate the if and then statements contained in the XML document.Accordingly, the rule block 130 evaluates the condition contained in theXML document 1710, and executes the then clause if the condition issatisfied. Results 1715 of the rule evaluation may be returned to theclient. In this manner, rules may be independently maintained by theclients 140 and changed at any time. A variety of functionalities may beprovided by the rule block 130 including, but not limited to: handlingfunctions with an unknown number of parameters, predefined trigonometricand logarithmic functions, user-defined custom functions, variablevalues resolved using a callback delegate, expressions which may containstring literals, where variable values, and function return values canbe strings, arithmetic operators such as +, −, /, *, ̂, Booleanoperators such as <, >, =, &, |, !, < >, >=, <=, and stringconcatenation with & or +. Functionality may be obtained from thirdparty libraries, such as bcParser.NET or others. In an analogous mannerto the data block 110, described above, the rule block 130 may be incommunication with a rule template cache (not shown). The rule templatecache may contain XML templates, one corresponding to each type of rule,and describe what logic to apply for each type.

In this manner, the rule block 130 may provide an engine for in-memoryevaluation of a rule. Software applications of any nature may postrequests to the rule block 130 to evaluate rules and return results ofthe evaluation. In this manner, the requesting application may not needto hard code rules and structure inside of their own applications.Accordingly, users may change the rules as needs and purposes change andthe applications are decoupled from the rule changes.

The rule block 130 may communicate with the messaging block 120 andsubscribe to or publish messages to the message bus. On receipt ofmessages of interest, the rule block 130 may take a specified action, asdescribed above, and a result of a rule evaluation may be to publish acertain type of message back to the message bus such that other systemsmay be notified of the action.

System Example: Text-to-Pledge System

Accordingly, embodiments of the platform 100 shown in FIG. 3 may be usedto implement a rules-based system dealing with substantially any kind ofcontent. The specifics of the contents, including attributes and methodsof particular objects, publishers, and subscribers are provided by theclients, while programming specifics concerning software code syntax,and database particulars, are provided by the platform 100. In thismanner, the platform 100 may be used to process data and rules, andmediate messages in any of a variety of systems, and maybe put to anyuse. As an example, an application is described below for processingcharity pledges made by individuals using mobile devices. Thisapplication is provided by way of example only, and it is to beunderstood that the platform 100 may be used in the service of virtuallyany end application.

Referring now to FIG. 19, a system 1800 is shown for processing charitypledges using an example of the platform 100. While charity pledges aregiven as an example, the system 1800 may generally be used to manage anytype of SMS campaign. A pledge database 1810 is coupled to the datablock 110 for storing pledge information including, but not limited to,email contact information, mobile phone numbers, and pledge amounts. Byutilizing the data block 110 to interface with the pledge database 1810,the pledge database may be changed without requiring any changes insoftware run by mobile contributors or the SMS gateway 1805, asgenerally described above.

An SMS gateway 1805 may be established as a publisher with the messagingblock 120. The messaging block 120 may, for example, expose a webservice to the SMS gateway 1805. In some embodiments an SMS messagepreparation block 1850 may be provided to format text messages receivedfrom the SMS gateway 1805 into messages suitable for the messaging block120, as generally described above. Any number of other subscribers mayalso be registered with the messaging block 120. A user may utilize amobile device 1815, to transmit a text message containing an amount of apledge they wish to make to the SMS gateway 1805. The mobile device 1815may take substantially any form including but not limited to, a cellphone or a digital assistant. Other devices, which may not be mobile,may also be used including a kiosk, a POS terminal, a set-top box, orother devices. The mobile device 1815 may also be utilized to text a‘help’ command to the SMS gateway 1805, as may be required by an SMSaggregator for the use of an SMS system in some examples. An owner of anSMS short code used to address text messages may be required to respondto such a ‘help’ message with instructions. Accordingly, the platform100 may be able to distinguish between a ‘pledge’ message containing apledge amount and a ‘help’ message requiring an instructional response.While a text messaging example has been described, the client device maycommunicate using other mechanisms, for example, a pledge may beinitiated through a web browser on the client device, an email message,another mobile web application, or through a native application on theclient device.

An incoming communication, such as a text message, sent from the mobiledevice 1815 may be received by the SMS gateway 1805 and packaged into amessage suitable for the messaging block 120 by the SMS messagepreparation block 1850. In other embodiments, the SMS gateway 1805itself may be configured to package the text message into a messagesuitable for the messaging block 120. The resulting message generated bythe SMS message preparation block 1850 may be passed to the messagingblock 120 and stored, for example using the data block 110. The datablock 110 may communicate information, such as pledge amounts, mobiledevice IDs and phone numbers, to the pledge database 1810. The storageof data using the data block 110 may cause the data block 110 to publisha message to a message bus of the messaging block 120. So, for example,the data block 110 may publish a message indicative of a ‘new messagereceived’ event onto the message bus. The rule block 130 may besubscribed to ‘new message received’ events, and may accordingly receivethe message. The rule block 130 may be configured to examine the messagestored in the data block 110 and take one of two actions: 1) publish apledge confirmation event to the message bus; or 2) publish a helpmessage event to the message bus, depending on whether the messagestored in the data block 110 was a pledge or help message. Other actionsmay be taken by the rule block in other embodiments.

A pledge confirmation system 1860 may be subscribed to pledgeconfirmation events, and receive a pledge confirmation message publishedto the message bus by the rule block 130. On receipt of the pledgeconfirmation message, the pledge confirmation system 1860 may beconfigured to, for example, email a confirmation message to the entitywho originated the pledge.

A help processing system 1865 may be subscribed to help message eventsand, on receipt of a help message event, the help processing system 1865may take action by sending a text message containing requisiteinstructions to a mobile phone ID associated with the event.

While SMS is used in this example, the mobile device 1815 may also run amobile web application for pledging. The mobile web application mayrecord a pledge amount and an associated mobile device ID, such as aphone number, or any other identifier of a user pledging, such as anemail address. Other information may be captured in other embodiments.

Point-of-Sale System

Embodiments of a platform according to the present invention may also beused to implement a point of sale system 1900, an example of which isshown in FIG. 20. A client device 1915 may be used to initiate a requestto place an order or publish content or data. The client device 1915 maybe any of a variety of electronic devices including, but not limited to,a cell phone, kiosk, or a point of sale terminal which may includepayment capability such as a credit card reader, or more generally anydevice with an Internet browser or messaging capability. The clientdevice 1915 may be mobile or fixed. An application operating on theclient device 1915 may be used to indicate what type of purchase isdesired. For example, a user at a concert or other event may indicatethey are interested in purchasing a concession, by for example,selecting a ‘concessions’ link or application on the client device 1915.

Responsive to the indication the user is interested in concessions, anapplication on the client device 1915 may communicate with the messagingblock 120 by, for example, calling a web service exposed by themessaging block 120, to publish a ‘looking for concessions’ message onthe message bus. In some embodiments, the client device 1915 maycommunicate with a gateway 1905 or other communication hub 1952 that inturn communicates with the messaging block 120, as shown in FIG. 20. Insome embodiments, a message preparation block 1950 may be used to formatmessages from the gateway 1905 or other communication hub 1952 for themessaging block 120. That is, an application operating on the clientdevice 1915 or gateway 1905 may be registered as a publisher with themessaging block 120 and may publish an event corresponding to a userindicating a desire for concessions. The messaging block 120 mayaccordingly identify subscribers to that type of message, as generallydescribed above. In some examples, a message preparation block 1950 maybe used between the gateway 1905 or other communication hub 1952 and themessaging block 120 to format a message in a suitable manner for themessaging block 120.

A concession manager 1917 application may be registered as a subscriberwith the messaging block 120, and may have a subscription to ‘lookingfor concessions’ messages. Accordingly, when the messaging blockpublishes such a message, the concession manager 1917 may be notified.The concession manager 1917 may access a concession inventory 1920accessible at a location where the user indicated his desire forconcessions. The data block 110 may facilitate data access and storageto the concession inventory 1920. The concession manager 1917 or thedata block 110 may publish a message to the message bus containinginformation about the types, sizes, promotions and other data pertainingto the concessions.

A profile manager 1925 application may also be registered as asubscriber with the messaging block 120, and may also have asubscription to ‘looking for concessions’ messages. Responsive to such amessage, the profile manager 1925 may utilize the data block 110 toaccess profile storage 1930 to access concession related preferences ofa user issuing the request for concessions. The profile manager 1925 ordata block 110 may then publish a message to the message bus containingthe user's concession related preferences.

The rule block 130 may be subscribed to the concession availabilitymessages and the profile messages published by the concession manager1917 and the profile manager 1925, respectively. The messages maycontain metadata indicating they are responsive to the same initialrequest from a user. Accordingly, on receipt of both messages at therule block 130, the rule block 130 may evaluate which of the concessionitems satisfy the concession preferences. For example, if one concessionpreference is for “large sizes”, the rule block 130 may return allavailable concessions that are of size large or bigger. The rule block130 may then publish a message to the message bus containingpreference-matched concessions.

The gateway 1905 or other communication hub 1952, or both, may besubscribed to the preference-matched concession messages, and may thencommunicate with the client device 1915 to display the choices specifiedby the preference-matched concession messages.

A user may then make a selection at the client device 1915 from amongthe preference-matched concession choices. The selection is communicatedto the gateway 1905 or other communication hub 1952, or both, that maypublish an order event to the message bus. Although not shown in FIG.20, an ordering system and a payment system may be subscribed to theorder messages and receive notification of the order.

Although an gateway 1905 and message preparation block 1950 are shown inFIG. 20, in other examples, a different interface may be provided to theplatform 100, such as a web interface or kiosk connection. The type ofinterface implemented will depend in part on the type of client deviceused. The platform 100 may have more than one interface to accommodate avariety of client device types. Generally, any number of communicationhubs may be present, and any number of client devices may communicatewith each hub.

Referring again to FIG. 20, in some examples, the client device 1915 maybe mobile. As a user enters a location, such as a store, they may berecognized by their client device 1915, for example through use of anRFID tag on the client device 1915 and a tag reader positioned at thelocation or by bluetooth communications. In some examples, otherpositioning technologies may be used such as GPS, cell towertriangulation, WiFi-based positioning, or combinations thereof. Thedetection of the user may be an event that is communicated to themessage bus of the platform 100. An identification of the user, theclient device 1915, or both, may also be published to the message bus.

The concession manager system 1917 may be subscribed to detected userevents, and may be notified of the user's presence at a location. Usingmethods as described generally above, the platform may then notify theclient device 1915 of available concessions or other items at thelocation which match preferences of the user. The notification mayproceed through generally any manner, including but not limited to SMS,email message, notification in an application on the mobile device, orcombinations thereof. In this manner, a retail location may interactwith the platform to notify incoming potential customers of items thatmatch one or more of the potential customer's preferences. The systemremains sufficiently robust that operation may continue if the retaillocation's database changes or migrates to a new data format.

From the foregoing it will be appreciated that, although specificembodiments of the invention have been described herein for purposes ofillustration, various modifications may be made without deviating fromthe spirit and scope of the invention.

Example 1

The following is an example of a code excerpt implementing a portion ofa data engine generic API. The code is commented to describe what eachportion accomplishes. The example is not intended to be limiting, othermethods, parameter types, values, databases, and languages may besupported in other examples.

  /// <param name=“Entity”>XML Payload to be passed to the   /// “asRoot identified” stored procedure.</param>   /// <paramname=“SPSuffix”>string to be appended before the   /// Root Name tobuild the stored procedure name to call.</param>   /// <paramname=“retType”>Enum specifying the return type   /// from this genericMethod.</param>   /// <returns>Returns an object corrsponding to None,  /// DataSet, DataReader or Scalar/String.</returns>   /// <example>This sample shows how to call the ExecuteSP method.   /// <code>   ///  /// localhost.DBAPI db = new localhost.DBAPI   /// db.ExecuteSP(@“  ///    <Person>   ///       <Param1 DATA_TYPE=“uniqueidentifier”>  /// ABCDEFAB-0000-1111-2222-333344445555}</Param1>   ///       <Param2DATA_TYPE=“nvarchar”>some text</Param2>   ///       <Param3DATA_TYPE=“int”>3</Param3>   ///    </Person>,   ///    “Create”,   ///   ReturnType.DataSet   ///    ”)   ///   /// </code>   /// </example>  /// this will execute the stored procedure uspCreatePerson   /// fromthe Database we are accessing   ///   /// First we load the Entity XMLPayload into a Memory stream   /// for fast access. Then we initializean XMLReader with the   /// Memory Stream. We use an XMLReader for fastforward traversing   /// of the Memory Stream. We traverse the EntityXML payload, grab   /// the Root and concatenate the Root to the literal  /// “usp” + SPSuffix resulting in the name of the stored procedure  /// we want to execute. Then we traverse the child elements of the  /// Entity XML Payload and for each node we build a DbParameter   ///corresponding to the element name and with the DBType parsed   /// asthe DATA_TYPE attribute of that element passed in parameters   ///Param1, Param2, Param3, ... ParamN will correspond to the   ///parameters of the Stored Procedure then we execute the DbCommand   ///either as an ExecuteNonQuery for ReturnType.None or as   ///ExecuteNonQuery for ResultType.Scalar, in this case though we   ///either read the scalar as one of the output params or we execute   ///DataAdapter.Fill(ds) to get a DataSet from the executed stored   ///  ///   private object ExecuteSP(    string Entity, string SPSuffix,ReturnType retType)   {    DbCommand cmd = null;   InitDBTemplateFromSOAPHeaders( ); //based on the existence of apassed    //in Soap Header we override the connection string from   //web-config with the one passed in the header      object ret =null;    try    {     ///we trace the entry point into this method weuse the ///Trace statement in order to be able to trace     /// onproduction boxes and to influence the level of     ///tracing with atrace-flag in the Web-Config    System.Diagnostics.Trace.WriteLineIf(traceSwitch.TraceVerbose,     “Info : Executing DBAPI.CreateEntity”);    System.Diagnostics.Trace.WriteLineIf(traceSwitch.TraceVerbose,     “Entity: ” + Entity);       /// we specify that the encoded way ofthe Entity payload was ASCII       Encoding en = Encoding.ASCII;      /// load the payload into a Memory Stream for fast access      MemoryStream s = new MemoryStream(en.GetBytes(Entity));      ///and then cosntruct a fast-forward only XmlTextReader totraverse       /// the payload sequentially       XmlTextReader xtr =new XmlTextReader(s);       string NodeValue = “”;       string NodeName= “”;       string NodeAttribute = “”;       string ParamDir = “”;      string ParamSize = “”;       int ParamSizeInt = 0;       ///weread the Root and grab the Name of the Element and concatenate       ///it to the name of the Stored Procedure       xtr.Read( );       stringEntitySchema = xtr.Name;       Encoding ascii = Encoding.ASCII;    ///CreateDbCommand is a private method that uses the DbProviderFactory object to ///generate the appropriate ADO.NET objects specificto a Data Provider     cmd = CreateDbCommand(SPSuffix.Length > 0 ?    ///_Procedure Name is initialized in the constructor of theWeb-Service as part of the ///DatabaseTemplate Schema;String.Format(_ProcedureName, EntitySchema, SPSuffix) : EntitySchema);    ///we loop and traverse the Entity payload looking for starting    /// of an XML Element, for attributes, for content     ///andeventually for the End Tag of an element; we save these     /// valuesin NodeValue, NodeAttribute and NodeName     while (xtr.Read( ))     {     switch (xtr.NodeType)      {       ///once we hit the start of anelement we grab both the       /// element Name as well as the value ofthe DATA_TYPE       /// attribute       case XmlNodeType.Element:       NodeName = string.Format(_ParameterFormat, xtr.Name);       NodeAttribute = xtr.GetAttribute(“DATA_TYPE”);        ParamDir =xtr.GetAttribute(“DIRECTION”);        ParamSize =xtr.GetAttribute(“SIZE”); break;       ///once we hit the NodeType Textwe know we found       /// the content of the Element       caseXmlNodeType.Text:        NodeValue = xtr.Value; break;       ///once wehit the NodeType CDATA we append the CDATA       /// content to the restof the content       case XmlNodeType.CDATA:        NodeValue += “ ” +xtr.Value;        NodeValue.Trim( ); break;       ///and once we findthe closing Tag of the XML Element       /// we look to see if all 3required information about the       ///element were found - if it isthe root or a malformed       /// element we skip it - and then weproceed with       ///the creation of a DbParameter corresponding to the      /// found information       case XmlNodeType.EndElement:        if(NodeName.Length > 0)        {         ///in case no DATA_TYPE attributewas found we         /// make the NodeAttribute “nvarchar” by default        if (NodeAttribute == null || NodeAttribute.Length == 0)         NodeAttribute = “String”;         ///in case no DIRECTIONattribute was found         /// we make the ParamDir IN by default        if (ParamDir == null || ParamDir.Length == 0)          ParamDir= “Input”;         ///in case there was a SIZE attribute found we        /// make the ParamSizeInt the integer         ///correspondingto the SIZE of the SqlParam         if (ParamSize != null &&ParamSize.Length > 0)          ParamSizeInt = int.Parse(ParamSize);        DbType dbType = DbType.String;         DbParameter p =_dbProvider.CreateParameter( );         if (ParamSizeInt > 0)         p.Size = ParamSizeInt;         ///the direction of theDbParamter is         ///assumed to be IN unless otherwise specified        ParameterDirection direction =         (ParameterDirection)Enum.Parse(         typeof(ParameterDirection), ParamDir, true);        p.ParameterName = NodeName;         p.Direction = direction;        p.Value = DBNull.Value;     ///this  function  adds  the generic  DbParameter  object  to  the  collection  of ///parameters ofthe Command object         AddDbParameter(p, ref cmd, NodeAttribute);        dbType = p.DbType;         ///if we don't find any value for theXML         /// Element then ignore this Parameter         ///after thatconvert the passed in XML         ///Element value to the appropriateSqlDbType         if (NodeValue.Length > 0)         {          switch(dbType)          {           case DbType.Guid:            p.Value = newSystem.Guid(NodeValue);            break;           caseDbType.DateTime:            p.Value = DateTime.Parse(NodeValue);           break;           case DbType.Int32:            p.Value =int.Parse(NodeValue);            break;           case DbType.Binary:           p.Value = ascii.GetBytes(             NodeValue.PadRight(90,‘F’));            break;           case DbType.Decimal:           p.Value = Decimal.Parse(NodeValue);            break;          case DbType.String:            p.Value = NodeValue;           break;           default:            p.Value = NodeValue;           break;          }         }         else          p.Value =System.DBNull.Value;         NodeName = NodeAttribute = “”;        NodeValue = ParamDir = ParamSize = “”;         ParamSizeInt = 0;       }        break;       default:       break;      }     }  ///dependent on the return type we execute a stored procedure whichreturns a ///DbDataReader, nothing, Scalar or a DataSet      switch(retType)      {       case ReturnType.DataReader:        DbDataReaderdr = cmd.ExecuteReader( );        StringBuilder sb = newStringBuilder(@“<RESPONSE>”);        while (dr.Read( ))        {        sb.AppendFormat(@“<{0}>”, EntitySchema);         for (int i = 0;i < dr.VisibleFieldCount; i++)       sb.AppendFormat(@“<{0}>{1}</{0}>”,dr.GetName(i),        dr.GetValue(i).ToString( ));        sb.AppendFormat(@“</{0}>”, EntitySchema);        }       dr.Close( );        sb.Append(@“</RESPONSE>”);        ret =sb.ToString( );        break;       case ReturnType.None:       cmd.ExecuteNonQuery( );        StringBuilder sbNone = newStringBuilder(@“<RESPONSE>”);        foreach (DbParameter p incmd.Parameters)        {         if (p.Direction ==ParameterDirection.Output ||          p.Direction ==ParameterDirection.InputOutput)         sbNone.AppendFormat(@“<{0}>{1}</{0}>”, p.ParameterName,          p.Value.ToString( ));        }       sbNone.Append(@“</RESPONSE>”);        ret = sbNone.ToString( );       break;       case ReturnType.Scalar:        ret =cmd.ExecuteScalar( );        break;       case ReturnType.DataSet:       DbDataAdapter da = _dbProvider.CreateDataAdapter( );       da.SelectCommand = cmd;        DataSet ds = new DataSet( );       da.Fill(ds);        ret = ds;        break;      }     }    catch (XmlException xe)     {     System.Diagnostics.Trace.WriteLineIf(traceSwitch.TraceError,      String.Format(@“ERROR reading XML in DBAPI.ExecuteSP(      Entity: {0}, SPSuffix: {1}, ReturnType: {2} >> Error: {3})”,      Entity, SPSuffix, retType, xe.Message));      throw (xe);     }    catch (DbException de)     {     System.Diagnostics.Trace.WriteLineIf(traceSwitch.TraceError,      String.Format(@“SQL ERROR in DBAPI.ExecuteSP(Entity: {0},       SPSuffix: {1}, ReturnType: {2} >> Error: {3})”,       Entity,SPSuffix, retType, de.Message));      throw (de);     }     catch(Exception x)     {     System.Diagnostics.Trace.WriteLineIf(traceSwitch.TraceError,      String.Format(@“ERROR in DBAPI.ExecuteSP(Entity: {0},       SPSuffix: {1}, ReturnType: {2} >> Error: {3})”,       Entity,SPSuffix, retType, x.Message));      throw (x);     }     finally     {     cmd.Connection.Close( );     }     return ret;   }

Example 2

In Example 1, the example API made use of the function CreateDbCommand.An example of an implementation of this command is:

private DbCommand CreateDbCommand(string CommandText) {  DbCommand cmd =_dbProvider.CreateCommand( );  cmd.CommandText = CommandText; cmd.CommandType = CommandType.StoredProcedure;  cmd.Connection =_dbConnection;  cmd.Connection.Open( );  return cmd; }

///_dbProvider is used to create the command. The Factory object_dbProvider, once properly constructed, knows how to instantiate theappropriate ADO.NET objects specific to each DataProvider. The_dbProvider object can be initialized with reference to the constructorof the Web-Service:

  public DBAPI( )   {    _providerName =   ConfigurationSettings.AppSettings[“providerName”];    _dbProvider =DbProviderFactories.GetFactory(_providerName);    _dbConnection =_dbProvider.CreateConnection( );    _dbConnection.ConnectionString =ConfigurationSettings.AppSettings[“Connection”];    InitCache( );   GDBCL.DatabaseTemplate DatabaseTemplate =   Context.Cache[_CacheKey]as GDBCL.DatabaseTemplate;    _ProcedureName =DatabaseTemplate.ProcedureName;    _ParameterFormat =DatabaseTemplate.ParameterFormat;    InitializeComponent( );   this._EventLogMachine =ConfigurationSettings.AppSettings[“EventLogMachine”];   this._EventLogName =   ConfigurationSettings.AppSettings[“EventLogName”];   this._EventLogSource =   ConfigurationSettings.AppSettings[“EventLogSource”];   this._TraceSwitch =   ConfigurationSettings.AppSettings[“TraceSwitch”];    traceSwitch =new TraceSwitch(this._TraceSwitch, “Trace     Switch for ” +this._EventLogName);    traceSwitch.Level =   (System.Diagnostics.TraceLevel)System.Int32.Parse(    ConfigurationSettings.AppSettings[“traceSwitch”]);   SetupListeners( );   }

/// The providerName is a String in the configuration file. Examples ofsuch a string are System.Data.Sq1Client or System.Data.OracleClient.Once we get an instance of the Provider Factory object, we can use it tocreate on the fly appropriate ADO.NET object for any Data Provider.

Example 3

An example of functions of a data engine generic API according to thepresent invention are shown below. Functions to manage entities intarget databases may be implemented using the ExecuteSP functiondescribed in Example 1. Specifically, in this example, four functionsfor managing an entity are implemented—CreateEntity, ReadEntity,UpdateEntity, and DeleteEntity. CreateEntity is implemented as follows:

[WebMethod] [SoapHeader(“dbwsHeader”,Direction=SoapHeaderDirection.In)]public string CreateEntity(string Entity) {  return ExecuteSP(Entity,“Create”, ReturnType.None).ToString( ); }

Similary, the other functions of the API are ExecuteSP_DataReader,ExecuteSP_DataSet, ExecuteSP_None, ExecuteSP_Scalar They all areimplemented by passing in appropriate parameters into the same function,ExecuteSP. For example ExecuteSP_DataReader is implemented as:

[WebMethod] [SoapHeader(“dbwsHeader”, Direction =SoapHeaderDirection.In)] public string ExecuteSP_DataReader(stringEntity) {  return (string)ExecuteSP(Entity, “”, ReturnType.DataReader);}

If you look back at the signature of the function ExecuteSP, you can seethat it has a very flexible signature that allows us to serve any typeof request from the previously presented functions:

private object ExecuteSP(string Entity, string SPSuffix, ReturnTyperetType)

Entity, represents the XML string passed into the API, SPSuffixrepresents a string that gets prepended to the passed in StoredProcedure Name. For example in the case of the CRUD functions presentedpreviously, the Create, Read, Update and Delete, suffixes can beprepended to the Stored Procedure name. In this manner, an Entity withthe same XML payloads as we showed previously as the Person Entity canbe managed. The third parameter allows different types of returnedobjects from the API.

Example 4

Examples of methods provided by an API implemented by the messagingengine 120 are provided below. In particular, the methods below are anexample of software code used to implement CreatePublisher,ReadPublisher, DeletePublisher, ReadSubscription, and CreateEvent foroperation with a BizTalk message bus. While BizTalk is used here as anexample, any messaging system, including a custom system, may be usedand appropriate software code drafted using the particularities of themessage system.

CreatePublisher

   [WebMethod]    public void CreatePublisher(Publisher Publisher)    {    ReceivePort rcvPort = CreateReceivePort(Publisher.Name);    CreateReceiveLocation(rcvPort, Publisher.TransportType,Publisher.ReceivePipeline,      Publisher.URL);    CreateSendPortGroup(Publisher.Name,    GetXmlFromFilter(Publisher.Filter));     _catalog.SaveChanges( );   }

The function of the CreatePublisher method is to create a publisherusing specific BizTalk objects. Basically, creation of a publisher inBizTalk may include: creating a ReceivePort with a same name as thePublisher, creating a ReceiveLocation associated with the ReceivePorthaving a same Name, TransportType, ReceivePipeline, and LocationURI ofthe Publisher, creating a SendPortGroup having a same Name and Filter asthe Publisher.

ReadPublisher   [WebMethod]   public Publishers ReadPublisher(stringPublisherName)   {    Publishers pubs = new Publishers( );    intpbsCount;    if (PublisherName.Length == 0)    {     pbsCount =_catalog.ReceivePorts.Count;     pubs.Publisher = newPublisher[pbsCount];     for(int i=0; i<pbsCount; i++)     pubs.Publisher[i] = GetPublisher(_catalog.ReceivePorts[i]);   }  else   {    pubs.Publisher = new Publisher[1];    pubs.Publisher[0] =   GetPublisher(_catalog.ReceivePorts[PublisherName]);   }   returnpubs;  }

This method creates a Publishers array, checks the PublisherName passedin for an empty name, returns publishers identified by that Name,allocates an array of Publisher objects when the PublisherName is emptyand adds publishers emitted by the BizTalk catalog object to the emptyPublisherName. The ReadPublisher method uses a GetPublisher method toimplement a search for a given Publisher by looking up the BizTalkobject-model starting with a ReceivePort object. An example of code usedto implement GetPublisher is:

  private Publisher GetPublisher(ReceivePort rPort)   {    Publisher pub= new Publisher( );    if (rPort.ReceiveLocations.Count == 0)     returnpub;    ReceiveLocation rLoc = rPort.ReceiveLocations[0];    pub.Name =rPort.Name;    pub.URL = rLoc.Address;    pub.TransportType =rLoc.TransportType.Name;    SendPortGroup spg =_catalog.SendPortGroups[pub.Name];    if (spg != null)     pub.Filter =GetFilterFromXml(spg.Filter);     return pub;   } DeletePublisher  [WebMethod]   public void DeletePublisher(string PublisherName)   {     DeleteSendPortGroup(PublisherName);     DeleteReceivePort(PublisherName);      _catalog.SaveChanges( );   }ReadSubscription   [WebMethod]   public SubscriptionsReadSubscription(Subscription subscription)   {    Subscriptions subs =new Subscriptions( );    Subscription s;    SendPortGroup spg;    intsbsCount = 0;    int index = 0;    if (subscription.PublisherName.Length== 0 && subscription.SubscriberName.Length == 0)    {     //get allsubscription     for (int i = 0;     i <_(—)catalog.SendPortGroups.Count; i++)      sbsCount +=    _catalog.SendPortGroups[i].SendPorts.Count;     subs.Subscription =new Subscription[sbsCount];     for (int i = 0; i <_(—)catalog.SendPortGroups.Count; i++)     {      for (int j = 0;      j<_(—) catalog.SendPortGroups[i].SendPorts.Count; j++)      {       s =new Subscription( );       s.PublisherName =_catalog.SendPortGroups[i].Name;       s.SubscriberName =((SendPort)_catalog.SendPortGroups[i].SendPorts[j]).Name;      subs.Subscription[index++] = s;      }     }    }    else if(subscription.PublisherName.Length == 0)    {     //get all subscriptionfor given subscriber     subs.Subscription =     newSubscription[_catalog.SendPortGroups.Count];     for (int i = 0; i<_(—)catalog.SendPortGroups.Count ; i++)     {      spg =_catalog.SendPortGroups[i];      for (int j = 0; j < spg.SendPorts.Count; j++)      {       if (((SendPort)spg.SendPorts[j]).Name ==      subscription.SubscriberName)       {        s = new Subscription();        s.PublisherName = spg.Name;        s.SubscriberName =subscription.SubscriberName;        subs.Subscription[index++] = s;      }      }     }   }   else if(subscription.SubscriberName.Length ==0)   {    // get all subscription for given Publisher    spg =_catalog.SendPortGroups[subscription.PublisherName];    sbsCount =spg.SendPorts.Count;    subs.Subscription = new Subscription[sbsCount];   for(int i = 0; i < sbsCount; i++)    {     s = new Subscription( );    s.PublisherName = subscription.PublisherName;     s.SubscriberName=((SendPort)spg.SendPorts[i]).Name;     subs.Subscription[i] = s;    }  }   else   {    //return empty array of subscriptions   subs.Subscription = new Subscription[1];    subs.Subscription[0] =subscription;   }   return subs;  }

The ReadSubscription method builds an array with all subscriptions inthe system when there is no given PublisherName and no givenSubscriberName as part of the incoming Subscription parameter. A totalnumber of SendPortGroups in the BizTalk database is retrieved and arrayof Subscriptions objects of that size allocated. A list of associatedSendPorts is retrieved for each SendPortGroup. For each SendPort, aSubscription object is created. The Subscription→PublisherName is set tothe SendPortGroup→Name. The Subscription→SubscriberName is set to thecurrent SendPort→Name in the iteration. The Subscription object isattached to the array of Subscriptions that will be returned.

CreateEvent   [WebMethod]   public void CreateEvent(Event vEvent)   {   Publishers pubs = ReadPublisher(vEvent.PublisherName);   foreach(Publisher pub in pubs.Publisher)    {     if(pub.TransportType == TransportType.file)     {      string GUID =System.Guid.NewGuid( ).ToString( );      string FileName =String.Format(@“{0}\{1}-{2}.xml”, pub.URL.Substring(0,      pub.URL.LastIndexOf(@“\”)), pub.Name, GUID);      StreamWriteroutFile = new StreamWriter(FileName, true);     outFile.Write(vEvent.Content);      outFile.Close( );     }    }  }

The CreateEvent method may allow clients to push an Event on a messagebus. The above implementation reflects a case when a Publisher pushesevents by copying an XML payload into a folder on a target machine.Other implementations may also be used. Generally, messages may bewritten by any mechanism to a Receive Port's location, from where themessage bus may pick the messages up and process them. The mechanismused to push a file into the Location of a Receive Port may include, butis not limited to, manually copying the files, an http post, or havingan application create files in a specific location.

The CreateEvent method above generally gets meta-data associated withthe Publishers of the Name passed in. For a zero-length PublisherName,all Publisher objects are obtained. For a given PublisherName, aspecific Publisher is obtained. For each Publisher object returned, theTransportType and URL of the Publisher is obtained. A file is created,with a name having a unique identifier. The Content field of the passedin Event object is written to the file, and the file is closed.

What is claimed is:
 1. A platform comprising: a core layer configured tomanipulate data and messages, the core layer comprising: a data blockconfigured to receive a data request from a client, the request beinggeneric to a plurality of database types, the data block configured toprocess the received database request into a specific database requestincluding syntax specific to a first database type; a messaging blockincluding a message bus, subscribers, and subscriptions, the messagingblock configured to receive a message from the client, store an eventbased on the message on the message bus, identify a subscriptionassociated with the event, and generate a notification regarding theevent for a subscriber associated with the identified subscription; anda rule block configured to receive a rule from the client including acondition and an action, the rule block configured to evaluate thecondition and execute the action; an adaptive layer coupled to the corelayer and configured to provide context to at least a portion of thedata manipulated by the core layer; and an intelligence layer coupled tothe adaptive layer and the core layer and configured to generateknowledge based in part on data manipulated by the core layer andcontext-enriched by the adaptive layer.
 2. The platform according toclaim 1 wherein the data block is separate from the client.
 3. Theplatform according to claim 1 wherein the data request pertains to adatabase coupled to the platform, the data request being independent ofthe pertinent database, and the platform configured to identify thepertinent database.
 4. The platform according to claim 3 wherein thepertinent database may be changed from a first database to a seconddatabase during a runtime of an application issuing the data request,the platform configured to update the identification of the pertinentdatabase from the first database to the second database.
 5. The platformaccording to claim 1 wherein the message received from the client doesnot contain information about a destination system, the informationabout the destination system provided by the messaging block.
 6. Asystem for processing monetary pledges, the system comprising: a messagebus configured to receive a first message containing informationoriginating from a client device; a data block configured to receive thefirst message from the message bus and process data contained in thefirst message for storage in a pledge database, the data blockconfigured to publish a second message to the message bus responsive toreceipt of the first message; a rule block configured to receive thesecond message received from the message bus and determine the secondmessage relates to a pledge, the rule block configured to publish apledge confirmation event to the message bus responsive to determiningthe second message relates to the pledge; and a pledge confirmationsystem subscribed to pledge confirmation events on the message bus, thepledge confirmation system configured to send a third message responsiveto notification of the pledge confirmation event.
 7. The systemaccording to claim 6 wherein the rule block is further configured toreceive the second message from the message bus and determine the secondmessage relates to a help event, the rule block configured to publish afourth message to the message bus responsive to determining the secondmessage relates to the help event; and the system further comprising ahelp processing system subscribed to messages relating to help events onthe message bus and configured to communicate help informationresponsive to notification of the fourth message.
 8. The systemaccording to claim 6 wherein at least a portion of the system comprisesa computer readable medium storing executable instructions, theexecutable instructions automatically generated by a processor based inpart on at least one stored template.
 9. A system for conducting a pointof sale transaction, the system comprising: a message bus configured toreceive a first message of a first type indicating a user is looking fora particular type of item; an inventory management applicationsubscribed to messages of the first type on the message bus andconfigured to receive a notification of the first message responsive toreceipt of the first message on the message bus, the inventorymanagement application configured to access an inventory database usinga data block and publish information to the message bus regarding theinventory of the particular type of item; a profile manager applicationsubscribed to messages of the first type on the message bus andconfigured to 1) receive a notification of the first message and 2)access preferences of the user responsive to the notification, theprofile manager application further configured to publish thepreferences of the user to the message bus; a rule block configured toreceive the published preferences of the user related to the particulartype of item and the information regarding the inventory of theparticular type of item, and evaluate at least one item in the inventoryagainst at least one of the published preferences, the rule blockconfigured to publish the at least one matching item to the message bus.10. The system according to claim 9 wherein the particular type of itemis at least one of a concession item, catalog, POS or inventory item.11. The system according to claim 9 wherein the information regardingthe inventory and the published preferences include metadata indicatingthe published preferences were retrieved responsive to a same userrequest.
 12. The system according to claim 9 wherein at least a portionof the system comprises a computer readable medium storing executableinstructions, the executable instructions automatically generated by aprocessor based in part on at least one stored template.
 13. A method ofautomatically generating an object in a target database having a type,the method comprising: receiving a payload including an entity name forcreation in the target database at least one attribute associated withthe entity name, the attribute having at least one parameter associatedwith the attribute; processing the payload using a template specific tothe type of target database, the template including a statement having aformat including at least one placeholder and a reference to at leastone placeholder template for replacing the at least one placeholder, thetemplate further including the placeholder template, the placeholdertemplate including a placeholder format and a fieldmask, the act ofprocessing including: replacing at least one placeholder in thestatement with the entity name; for each attribute associated with theentity in the payload, generating a string having the placeholder formatand containing at least one parameter from the payload placed in theformat as specified by the fieldmask; concatenating each of therespective strings generated for all attributes and replacing the atleast one placeholder with the concatenated strings; executing thecompleted statement to generate the object in the target database. 14.The method according to claim 13 wherein the payload and the templatecomprises an XML schema.
 15. The method according to claim 13 whereinthe object comprises a table.
 16. A system for automatically generatingan object in a target database, the system comprising: a template memorystoring at least one statement template, the template including ageneric expression of a plurality of commands necessary to create theobject in the target database and at least one data placeholder; anauto-generation engine configured to receive a call to generate theobject in the target database, the call including a payload, theauto-generation engine further configured to load the template, replacethe at least one data placeholder with at least a portion of thepayload, and execute the statement to generate the object in the targetdatabase.
 17. The system according to claim 16 wherein the template isan XML schema and the auto-generation engine includes a web service. 18.The system according to claim 16 wherein the object includes a table.